From nobody Sun Jun 4 06:15:13 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06888129B26 for ; Sun, 4 Jun 2017 06:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNhIRBsNVEh5 for ; Sun, 4 Jun 2017 06:15:07 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0117.outbound.protection.outlook.com [104.47.37.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EA6129B1E for ; Sun, 4 Jun 2017 06:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k4+lt3SaF5mm1Y3+k9UatFbmp7Idy0ajbjPwvlYIFh8=; b=S6zB39IGCe/LrZf4Z+YO+fhk5OMUbaCWijLPK+wjvPGLjkKgkJG/LAFC2Gcw0nIz54wUHc8Br8AL/A1MTt5Dfwq+/e/gmL5otZ+HUScmLpZRrEmFpiREeV/2orZzS3nJzesp8TOZbL5nve5R68P+2uDWHJWFogS5tjpKQBs+qyA= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0471.namprd21.prod.outlook.com (10.172.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.0; Sun, 4 Jun 2017 13:15:05 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1178.000; Sun, 4 Jun 2017 13:15:05 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: Initial JSON Web Token Best Current Practices Draft Thread-Index: AdLdLiuU8v8bzUlIS+Ocr4mmEw/lEAABln+Q Date: Sun, 4 Jun 2017 13:15:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-04T06:15:03.7943646-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0471; 7:c526aC9Ljp08vyu4DyIo2Hv9QsaHXjucyd8bg9XRvLOalQD53WBMJm4Zuh5igCIwhi7PukZ0Y9GKVZSPqgLNMNRgxICySH94Om9gRdk/Vr/ndbcWPKq8Shk5fVMkiK8K2Rr7DNTuSaJHRkMotS6PYjycjrMm1TjTzHGIK5LXcJ3xlV6/9iF0NPGvqIW3eMNV589U6mTDIQlhkIUk2xsPctv/MLkBXZ6eAl3SD1Myny8HfB7lrP+7Q8WKcXpfZLvWLfQtj+RlQY/uwCsy5RBp3UUP4xx2PU4lFrPErmxbjwpfoM2bG8DGB58HPi6kHJMqr9zGagqEh0BdrxT3bFWNewRu14ZP9oCu182F7VojA6o= x-ms-office365-filtering-correlation-id: a9f27185-5dfb-4f96-7066-08d4ab4bb77e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0471; x-ms-traffictypediagnostic: CY4PR21MB0471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0471; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0471; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39450400003)(39400400002)(39410400002)(39850400002)(209900001)(377454003)(69234005)(33656002)(6506006)(3660700001)(122556002)(8936002)(77096006)(556974002)(81166006)(8676002)(5630700001)(236005)(55016002)(2473003)(6306002)(99286003)(9686003)(54896002)(6116002)(53936002)(2900100001)(189998001)(6436002)(606005)(54356999)(229853002)(5640700003)(76176999)(50986999)(2351001)(3846002)(102836003)(10290500003)(10090500001)(25786009)(478600001)(53376002)(53546009)(790700001)(14454004)(2501003)(7736002)(74316002)(7906003)(72206003)(5005710100001)(5660300001)(8990500004)(966005)(38730400002)(110136004)(2950100002)(66066001)(6916009)(86362001)(7696004)(3280700002)(86612001)(2906002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0471; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504A1A40A14747787EA8D93F5F50CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2017 13:15:05.2333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0471 Archived-At: Subject: [Id-event] FW: Initial JSON Web Token Best Current Practices Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 13:15:12 -0000 --_000_CY4PR21MB0504A1A40A14747787EA8D93F5F50CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Sent as an FYI. Please send responses to oauth@ietf.org.] From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Sunday, June 4, 2017 6:13 AM To: oauth@ietf.org Subject: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) fu= nctions underlying them are now being widely used in diverse sets of applic= ations. During IETF 98 in Chicago, we discus= sed reports of people implementing and using JOSE and JWTs insecurely, the = causes of these problems, and ways to address them. Part of this discussio= n was an invited JOSE/JWT Security Update presentation th= at I gave to two working groups, which included links to problem reports an= d describes mitigations. Citing the widespread use of JWTs in new IETF app= lications, Security Area Director Kathleen Moriarty suggested during these = discussions that a Best Current Practices (BCP) document be written for JSO= N Web Tokens (JWTs). I'm happy to report that Yaron Sheffer, Dick Hardt, and myself have produce= d an initial draft of a JWT BCP. Its abstract is: JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of clai= ms that can be signed and/or encrypted. JWTs are being widely used and depl= oyed as a simple security token format in numerous protocols and applicatio= ns, both in the area of digital identity, and in other application areas. T= he goal of this Best Current Practices document is to provide actionable gu= idance leading to secure implementation and deployment of JWTs. In Section 2, we describe threats and vulnerabilities. In Section 3, we de= scribe best practices addressing those threats and vulnerabilities. We bel= ieve that the best practices in Sections 3.1 through 3.8 are ready to apply= today. Section 3.9 (Use Mutually Exclusive Validation Rules for Different= Kinds of JWTs) describes several possible best practices on that topic to = serve as a starting point for a discussion on which of them we want to reco= mmend under what circumstances. We invite input from the OAuth Working Group and other interested parties o= n what best practices for JSON Web Tokens and the JOSE functions underlying= them should be. We look forward to hearing your thoughts and working on t= his specification together. The specification is available at: * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1690 and a= s @selfissued. --_000_CY4PR21MB0504A1A40A14747787EA8D93F5F50CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Sent as an FYI. = Please send responses to oauth@ietf.org.]

 

From: OAuth [mailto:oauth-bounces@ietf.org] <= b>On Behalf Of Mike Jones
Sent: Sunday, June 4, 2017 6:13 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Initial JSON Web Token Best Current Practices Dr= aft

 

JSON Web Tokens (JWTs) and the JSON Object Signing a= nd Encryption (JOSE) functions underlying them are now being widely used in= diverse sets of applications.  During IETF 98 in Chicago, we discuss= ed reports of people implementing and using JOSE and JWTs insecurely, the c= auses of these problems, and ways to address them.  Part of this discu= ssion was an invited JOSE/JWT Security Update presentation that I gave to two working groups= , which included links to problem reports and describes mitigations.  = Citing the widespread use of JWTs in new IETF applications, Security Area D= irector Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written = for JSON Web Tokens (JWTs).

 

I’m happy to report that Yaron Sheffer, Dick H= ardt, and myself have produced an initial draft of a JWT BCP.  Its abs= tract is:

JSON Web Tokens, also kno= wn as JWTs [RFC7519], a= re URL-safe JSON-based security tokens that contain a set of claims that ca= n be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numero= us protocols and applications, both in the area of digital identity, and in= other application areas. The goal of this Best Current Practices document = is to provide actionable guidance leading to secure implementation and deployment of JWTs.

 

In Section 2, we describe threats and vulnerabilitie= s.  In Section 3, we describe best practices addressing those threats = and vulnerabilities.  We believe that the best practices in Sections 3= .1 through 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) = describes several possible best practices on that topic to serve as a start= ing point for a discussion on which of them we want to recommend under what= circumstances.

 

We invite input from the OAuth Working Group and oth= er interested parties on what best practices for JSON Web Tokens and the JO= SE functions underlying them should be.  We look forward to hearing yo= ur thoughts and working on this specification together.

 

The specification is available at:

  • <= a href=3D"https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00">https= ://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00

    •  

    An HTML-formatted version is also available at:=

    • <= a href=3D"http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html"= >http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html<= /o:p>

     

            &nbs= p;             =             &nb= sp;            =         -- Mike

     

    P.S. This notice was also posted at http://self-issued.info/?p=3D1690 and as @selfissued.

--_000_CY4PR21MB0504A1A40A14747787EA8D93F5F50CY4PR21MB0504namp_-- From nobody Thu Jun 8 18:28:41 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7DE12EB19 for ; Thu, 8 Jun 2017 18:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_oA7RSISlaJ for ; Thu, 8 Jun 2017 18:28:38 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D20612EB14 for ; Thu, 8 Jun 2017 18:28:38 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id r63so26611000itc.1 for ; Thu, 08 Jun 2017 18:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YxfLzmdBlSWLRYLcsa9ic8VekHlYPB7L+7GQSbA1Yo0=; b=cAP8bE9zjKi14RXoFpZ0GybwhzYE0UZL2lNH4HFcgXx5B4RV/35XYomclKbN1HaVDf XfHtk7Aa4+AIPQHCuGuvYH4FBzSoMBPPGNtRbC4bbId/2624FarXcv0p4eKiLphs44xr ZRQ99nnHa6ALoYN8gs45u9zbEzUk/BsKkxh8fwrs5ybaAaIetiyImO7RHJ6mujbnfgUo RnUawgw37C8Hzxk4NqwwDNzh1PgPOGq21dYSFcHwAm7qhMOxhKHizRz099GTdVmeoznm 8J3gjo+2dT0dEl+kzwDWsqdYv05UikXdH6LOtixmjFOet9ZVDJasagPNrPMvg5MUICc0 LEYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YxfLzmdBlSWLRYLcsa9ic8VekHlYPB7L+7GQSbA1Yo0=; b=FsOsJMAbfUoeDMCJlTdp/KiNqlSuk4mPQ71Nz2zvYy6C7/pTb0/1ZLgLZa6lgspAKO H6/UB/Kl+YJv0lKHnqOzVF8X5+GeZLsM1/E0YKoo2VNVS6BR1ydvqlEo5bd0lP0WW5Vu Qruy/PjtDm8aVF8gzUABVE42JhcpMQQF11VbhLgzMW8vLrGOpu7YUxwlVqMEBkN9AKYt cbNJnyxvFN+1S5D/IpnPvTzQ+fB8Ko9aKdpuBs55FXLPftF6XHC1Nl2M40WqMwF0cqQ8 91bQKPTX2YnAHeCcLPQuiqHiNLP/x09rGwoCXwl9hZJvRQmi3cWVUQwzEg2I0KWIeDkS FKWA== X-Gm-Message-State: AODbwcB+7xzCEqFTwCsf9BUkXGyYW1awTIbfy+wRK3apDJvu5uUxR5Kf hq4fR1bckg63ERD4Oesz6mgq0CtmSj/5kac= X-Received: by 10.36.108.131 with SMTP id w125mr8548643itb.91.1496971717100; Thu, 08 Jun 2017 18:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.71 with HTTP; Thu, 8 Jun 2017 18:28:16 -0700 (PDT) From: Marius Scurtescu Date: Thu, 8 Jun 2017 18:28:16 -0700 Message-ID: To: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a1147e2a4704e0e05517ce3e1" Archived-At: Subject: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 01:28:40 -0000 --001a1147e2a4704e0e05517ce3e1 Content-Type: text/plain; charset="UTF-8" There were a couple of proposals on how to distinguish SETs from Id Tokens and Access Tokens in such a way that naive implementations will not confuse one for the other and open up security vulnerabilities. There is also another important requirement: the SET issuer in some cases must be different from the "sub" issuer. This is the case of an RP sending SETs to an IdP. With these requirements in mind I propose the following: - both "sub" and "iss" to be defined at the event level - "iss" at event level and at top SET level can be different - "iss" and "sub" at event level can be different across events in the same SET - "sub" should NOT be present at the top SET level (this solves the disambiguation), please note "should" and not "must" This solution also allows different profiles that define event types to define additional claims related to sub (like email or phone_number) and since all these claims will be at the event level there will be no collisions or ambiguity. Another proposal (which I supported) was to define a composite "aud" claim. This is not solving the requirement for a distinct SET issuer. Also, having the same claim name having different syntax in different token types could lead to confusion. And yet another proposal was to introduce a new claim for JWTs that defines a "type". This is not practical in the short term, and it also is not solving the distinct issuer requirement, but I think this is something the JWT group should seriously consider. Thoughts? Marius --001a1147e2a4704e0e05517ce3e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There were a couple of proposals on how to distinguish SET= s from Id Tokens and Access Tokens in such a way that naive implementations= will not confuse one for the other and open up security vulnerabilities.
There is also another important requirement: the SET issu= er in some cases must be different from the "sub" issuer. This is= the case of an RP sending SETs to an IdP.

With th= ese requirements in mind I propose the following:
- both "su= b" and "iss" to be defined at the event level
- &q= uot;iss" at event level and at top SET level can be different
- "iss" and "sub" at event level can be different acr= oss events in the same SET
- "sub" should NOT be presen= t at the top SET level (this solves the disambiguation), please note "= should" and not "must"

This solutio= n also allows different profiles that define event types to define addition= al claims related to sub (like email or phone_number) and since all these c= laims will be at the event level there will be no collisions or ambiguity.<= /div>

Another proposal (which I supported) was to define= a composite "aud" claim. This is not solving the requirement for= a distinct =C2=A0SET issuer. Also, having the same claim name having diffe= rent syntax in different token types could lead to confusion.
And yet another proposal was to introduce a new claim for JWTs = that defines a "type". This is not practical in the short term, a= nd it also is not solving the distinct issuer requirement, but I think this= is something the JWT group should seriously consider.

=
Thoughts?

Marius
--001a1147e2a4704e0e05517ce3e1-- From nobody Thu Jun 8 18:32:19 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10211270A0 for ; Thu, 8 Jun 2017 18:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94BlhtWnd3eb for ; Thu, 8 Jun 2017 18:32:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73BA1242EA for ; Thu, 8 Jun 2017 18:32:16 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v591WE1T020280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Jun 2017 01:32:14 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v591WEYO010303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Jun 2017 01:32:14 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v591WE8J010312; Fri, 9 Jun 2017 01:32:14 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Jun 2017 18:32:14 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 8 Jun 2017 18:32:12 -0700 Cc: ID Events Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> References: To: Marius Scurtescu X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 01:32:19 -0000 +1 Phil > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu wrote= : >=20 > There were a couple of proposals on how to distinguish SETs from Id Tokens= and Access Tokens in such a way that naive implementations will not confuse= one for the other and open up security vulnerabilities. >=20 > There is also another important requirement: the SET issuer in some cases m= ust be different from the "sub" issuer. This is the case of an RP sending SE= Ts to an IdP. >=20 > With these requirements in mind I propose the following: > - both "sub" and "iss" to be defined at the event level > - "iss" at event level and at top SET level can be different > - "iss" and "sub" at event level can be different across events in the sam= e SET > - "sub" should NOT be present at the top SET level (this solves the disamb= iguation), please note "should" and not "must" >=20 > This solution also allows different profiles that define event types to de= fine additional claims related to sub (like email or phone_number) and since= all these claims will be at the event level there will be no collisions or a= mbiguity. >=20 > Another proposal (which I supported) was to define a composite "aud" claim= . This is not solving the requirement for a distinct SET issuer. Also, havi= ng the same claim name having different syntax in different token types coul= d lead to confusion. >=20 > And yet another proposal was to introduce a new claim for JWTs that define= s a "type". This is not practical in the short term, and it also is not solv= ing the distinct issuer requirement, but I think this is something the JWT g= roup should seriously consider. >=20 > Thoughts? >=20 > Marius > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx= 2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D= =20 From nobody Thu Jun 8 18:56:16 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B31129329 for ; Thu, 8 Jun 2017 18:56:14 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matake-jp.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGFElB3Kc-MK for ; Thu, 8 Jun 2017 18:56:11 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6324F1289B5 for ; Thu, 8 Jun 2017 18:56:11 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id a136so24432037lfa.0 for ; Thu, 08 Jun 2017 18:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matake-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UaMU2snDu9W/dWs09TiBnhqJtznGyjR5MxD3a6FGMP0=; b=C/0GsX6PzI89XEGPP4u8VRDg37TUlvGRwAGuiES7R0u79CIuQnGzlRsuVMXIscyqpJ NtuADcLtWGmIYMUUUB7YWwWt7Ahz99P2+iDZ3zo7hezhaE5KC8NK16pcpymypwSttATE zaGQ/G6bGHSoI12u0mvqDqmO/3sz6yrI5CB7avE9GahdN9SldTfDBa3grONkGTUp7Oc5 O6zBT+3VilPZ44pruXR6jtChtctxXP7ZGyctqfAzvkka4JezCtXTblBCB6ydgMEnpvgo IXOPbvEC929YxXGtu5fNVsUyZCNPtmm65kEihkkJ/OsMn/mDv1BSXmBxAn/CrLViAr5/ afjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UaMU2snDu9W/dWs09TiBnhqJtznGyjR5MxD3a6FGMP0=; b=EA4A8VWQqc4Et9F9IMQY/9+DLFqXN1wxLAdxOpv44p18Zlwd04xNtyP7mAutU4s1XE aFoJ/dW1THhnMezeWsaGXf2iyfnlKhXTze9UlvDrFlS+Uv+k4JwTAOdhyhoGCqbgsHKi V6vgpfffW/Hg4xpnEo7ZUYcxfYvuTrgQWmuBue5V+ejCqXmt0AOAucCFQLVOyqEcx9S+ im9C9pDGT5UZDbVkPekcia/yeGUOhMTPxdar/+bumYoPSaltSLyouN9qx2KbpegrH0Qk iVPZ+xsyFLqylpBVSnlTcxbPDiCyK54GnlflESY4EuG6PZJXuUrKpVpVXM4ihExlxXKP 4qwA== X-Gm-Message-State: AODbwcClp6YpFEJJ++vlsRlHhElA9RlcWFnUeAYxAe2FNFfQ3LQDALeN tXlOgYXCxY46ETvQv+CxekAGgqyD78JH X-Received: by 10.25.193.68 with SMTP id r65mr4791773lff.150.1496973369467; Thu, 08 Jun 2017 18:56:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.204.202 with HTTP; Thu, 8 Jun 2017 18:56:09 -0700 (PDT) X-Originating-IP: [113.42.16.83] In-Reply-To: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> From: "matake, nov" Date: Fri, 9 Jun 2017 10:56:09 +0900 Message-ID: To: "Phil Hunt (IDM)" Cc: Marius Scurtescu , ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c19c9a4ecfb3d05517d454d" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 01:56:14 -0000 --94eb2c19c9a4ecfb3d05517d454d Content-Type: text/plain; charset="UTF-8" +1 especially for "type" 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) : > +1 > > Phil > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > wrote: > > > > There were a couple of proposals on how to distinguish SETs from Id > Tokens and Access Tokens in such a way that naive implementations will not > confuse one for the other and open up security vulnerabilities. > > > > There is also another important requirement: the SET issuer in some > cases must be different from the "sub" issuer. This is the case of an RP > sending SETs to an IdP. > > > > With these requirements in mind I propose the following: > > - both "sub" and "iss" to be defined at the event level > > - "iss" at event level and at top SET level can be different > > - "iss" and "sub" at event level can be different across events in the > same SET > > - "sub" should NOT be present at the top SET level (this solves the > disambiguation), please note "should" and not "must" > > > > This solution also allows different profiles that define event types to > define additional claims related to sub (like email or phone_number) and > since all these claims will be at the event level there will be no > collisions or ambiguity. > > > > Another proposal (which I supported) was to define a composite "aud" > claim. This is not solving the requirement for a distinct SET issuer. > Also, having the same claim name having different syntax in different token > types could lead to confusion. > > > > And yet another proposal was to introduce a new claim for JWTs that > defines a "type". This is not practical in the short term, and it also is > not solving the distinct issuer requirement, but I think this is something > the JWT group should seriously consider. > > > > Thoughts? > > > > Marius > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c= > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --94eb2c19c9a4ecfb3d05517d454d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 especially for "type"

2017-06-09 10:32 GMT+09:00 Phil Hun= t (IDM) <phil.hunt@oracle.com>:
+1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
>
> There were a couple of proposals on how to distinguish SETs from Id To= kens and Access Tokens in such a way that naive implementations will not co= nfuse one for the other and open up security vulnerabilities.
>
> There is also another important requirement: the SET issuer in some ca= ses must be different from the "sub" issuer. This is the case of = an RP sending SETs to an IdP.
>
> With these requirements in mind I propose the following:
> - both "sub" and "iss" to be defined at the event = level
> - "iss" at event level and at top SET level can be different=
> - "iss" and "sub" at event level can be different = across events in the same SET
> - "sub" should NOT be present at the top SET level (this sol= ves the disambiguation), please note "should" and not "must&= quot;
>
> This solution also allows different profiles that define event types t= o define additional claims related to sub (like email or phone_number) and = since all these claims will be at the event level there will be no collisio= ns or ambiguity.
>
> Another proposal (which I supported) was to define a composite "a= ud" claim. This is not solving the requirement for a distinct=C2=A0 SE= T issuer. Also, having the same claim name having different syntax in diffe= rent token types could lead to confusion.
>
> And yet another proposal was to introduce a new claim for JWTs that de= fines a "type". This is not practical in the short term, and it a= lso is not solving the distinct issuer requirement, but I think this is som= ething the JWT group should seriously consider.
>
> Thoughts?
>
> Marius
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1= YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkI= TSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvg= Xzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJ= LhxWI&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--94eb2c19c9a4ecfb3d05517d454d-- From nobody Thu Jun 8 21:02:17 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC00D127275 for ; Thu, 8 Jun 2017 21:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyQccY4NUFEG for ; Thu, 8 Jun 2017 21:02:14 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928FF1292C5 for ; Thu, 8 Jun 2017 21:02:14 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id g66so24081898vki.1 for ; Thu, 08 Jun 2017 21:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z82Qef7gHPOBHOuGgIcn1xvDcJ8ocbbVX+YYkxE1ASo=; b=MinC9b3NaYrjBmujrWfzDJ8zk9U4Ty/mhrKnylKsoxBt+NxZZtOrTC9dT15FZGU3Eu wFWHKWj9jeMtw9skm4+xd9pySuW0dY7y0ZxNapDaEo+cNKC44UKEX89nGCf228jAClLn yJK1lxNReGKA1DOh2AqHAgEWcfScB6Dql6Uonk4f2r6Glc1dqE18Ls7lXd57CELyVJO9 dHih+tbfcveIS6Un6Tm/EeGOIA/HmlBjaqNKAV24OaRkpFzGGUPrQ5ez/fNEEXc/lj5P SnbJGn2T0QQxx5c+hQPdtVpxQFhtAoFisL0362Nzqa4GdXFGiowlldhGt4QFfEHXHXws kc7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z82Qef7gHPOBHOuGgIcn1xvDcJ8ocbbVX+YYkxE1ASo=; b=Nuo3kq88z/YtZScIsuoF18oDkBhXT2SAGmzGsTYtBzZhoyVyrxgcPzy8Y+n6ZgAB3U H6Wg1GfmduftVNFcB88MKg9HK6mUUWhWnNBMHej9dro66D3mg8xZJx08sFz912lZ8z9+ aK9w3VSDCHIV9PocZ/uFqAAj+4O+GxZnApQg9xYgJoSTf/5jxoiOFj7gYNRBMNgdGStD gYOoR9WXnqr6RlTdhCf0gvVBC2r9+51XFxDzoEAJTY6gIyWK7IfI2hIBVNAEYGpoeVJZ nO/UOWKVt69oZ2OahpJXBEujpsmr1TN/Plfty5HlFRFu8NZq9KwRB6VmGRABERY0GgfB Imcg== X-Gm-Message-State: AODbwcCEL2e+oLbrf14sZVgpsza9+9oc/BVxL5lxbmf0ICkljPbxwRQS NEq6cDw02TKWVdcCOrA5DDopl0gn4P5J X-Received: by 10.31.185.18 with SMTP id j18mr20300418vkf.149.1496980933599; Thu, 08 Jun 2017 21:02:13 -0700 (PDT) MIME-Version: 1.0 References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> In-Reply-To: From: Adam Dawes Date: Fri, 09 Jun 2017 04:02:00 +0000 Message-ID: To: "Phil Hunt (IDM)" , "matake, nov" Cc: ID Events Mailing List , Marius Scurtescu Content-Type: multipart/alternative; boundary="001a11439efac8dcc505517f0862" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 04:02:17 -0000 --001a11439efac8dcc505517f0862 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was initially a fan of keeping SETS to be very similar to id tokens but I now think this is a better plan. On Thu, Jun 8, 2017 at 6:56 PM matake, nov wrote: > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) : > >> +1 >> >> Phil >> >> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> wrote: >> > >> > There were a couple of proposals on how to distinguish SETs from Id >> Tokens and Access Tokens in such a way that naive implementations will n= ot >> confuse one for the other and open up security vulnerabilities. >> > >> > There is also another important requirement: the SET issuer in some >> cases must be different from the "sub" issuer. This is the case of an RP >> sending SETs to an IdP. >> > >> > With these requirements in mind I propose the following: >> > - both "sub" and "iss" to be defined at the event level >> > - "iss" at event level and at top SET level can be different >> > - "iss" and "sub" at event level can be different across events in the >> same SET >> > - "sub" should NOT be present at the top SET level (this solves the >> disambiguation), please note "should" and not "must" >> > >> > This solution also allows different profiles that define event types t= o >> define additional claims related to sub (like email or phone_number) and >> since all these claims will be at the event level there will be no >> collisions or ambiguity. >> > >> > Another proposal (which I supported) was to define a composite "aud" >> claim. This is not solving the requirement for a distinct SET issuer. >> Also, having the same claim name having different syntax in different to= ken >> types could lead to confusion. >> > >> > And yet another proposal was to introduce a new claim for JWTs that >> defines a "type". This is not practical in the short term, and it also i= s >> not solving the distinct issuer requirement, but I think this is somethi= ng >> the JWT group should seriously consider. >> > >> > Thoughts? >> > >> > Marius >> > _______________________________________________ >> > Id-event mailing list >> > Id-event@ietf.org >> > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0= 57SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxW= I&e=3D >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --=20 Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 --001a11439efac8dcc505517f0862 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was initially a fan of keeping SETS to be very sim= ilar to id tokens but I now think this is a better plan.=C2=A0

+1 especially for "type"

2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
+1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <mscurtescu@google.com> wrote:<= br> >
> There were a couple of proposals on how to distinguish SETs from Id To= kens and Access Tokens in such a way that naive implementations will not co= nfuse one for the other and open up security vulnerabilities.
>
> There is also another important requirement: the SET issuer in some ca= ses must be different from the "sub" issuer. This is the case of = an RP sending SETs to an IdP.
>
> With these requirements in mind I propose the following:
> - both "sub" and "iss" to be defined at the event = level
> - "iss" at event level and at top SET level can be different=
> - "iss" and "sub" at event level can be different = across events in the same SET
> - "sub" should NOT be present at the top SET level (this sol= ves the disambiguation), please note "should" and not "must&= quot;
>
> This solution also allows different profiles that define event types t= o define additional claims related to sub (like email or phone_number) and = since all these claims will be at the event level there will be no collisio= ns or ambiguity.
>
> Another proposal (which I supported) was to define a composite "a= ud" claim. This is not solving the requirement for a distinct=C2=A0 SE= T issuer. Also, having the same claim name having different syntax in diffe= rent token types could lead to confusion.
>
> And yet another proposal was to introduce a new claim for JWTs that de= fines a "type". This is not practical in the short term, and it a= lso is not solving the distinct issuer requirement, but I think this is som= ething the JWT group should seriously consider.
>
> Thoughts?
>
> Marius
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&= ;m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwV= qXoVpn88YKOCd0mxPQFJLhxWI&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--
Adam Dawes=C2=A0|<= /span>=C2=A0Sr. Product Manage= r=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

--001a11439efac8dcc505517f0862-- From nobody Thu Jun 8 21:59:44 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0641294EF for ; Thu, 8 Jun 2017 21:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YITvvh8Zem6F for ; Thu, 8 Jun 2017 21:59:41 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F4E128B8E for ; Thu, 8 Jun 2017 21:59:41 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m47so133059977iti.1 for ; Thu, 08 Jun 2017 21:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2CkZwu571SNYIo2Ggo1ChcTgl2o86FTfAz8AuvT6hdU=; b=ibS37VGGb023fiIX1iLRYXByMDSU+HPBAXesihrR6fJOfnXpU6t4D9iySzHckl12KH z/4J5dDxGfDOA8hhdwWq2Q+sMZYuhUlFcj8FXX+C8xck1HK44Cx1U8Rjc5F74ycanazJ iSAP9Wfxxhf8E6h1I+kn/kiYgsFffrp3COimpwO+Wq/dOOZCuU0DokRz8lNdTgvvq6KO hhLTRpi4YkNZLwIiTCKK/9NOgnfhM7viZUIgwl0k/Zbxz/LRiFakliMmkgbOFIO4kyvw EWNuXF/WV6arTXkZE6cCqyXJpJk5paoEGEhYvEOh32jy2dOQN6MuP9ql7yQ8L5JmvnGP ffyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2CkZwu571SNYIo2Ggo1ChcTgl2o86FTfAz8AuvT6hdU=; b=J9DC+GTJ8sApuQEFVGAyXkwMX58DAd781bcKO/IAEbMch/VbK2tkpcr237a8tMhntG EH2fQVrEC+h1au2snGKND45Pv4BCK2rjIVKn/mBLNV6U59hNiw+zT6ZprxeShxHIrnIG 2onOeihxV5CAgVuFs5famo0ti9oKnw9LgH6Z+mN3KEmIZQLGnt01v4ONGzZdRgSe1yWg Iq2g6mGWRc7ftUm+5sRuBbb7Yw9hlRMcirzD0SZSqMridUHJvc+14tmmsy7hP37hUT0Z LAEA5+DQK1L8UAvNGmgb3ze4eAB5MhZMXKwKuKXlMdILH8cn4H4bGfHvg+JnuCNkUnY6 1igg== X-Gm-Message-State: AODbwcA6d7GmTyB/xf+MX4o/mSlETpJX9SJWFDJZiQ7/g7x+Zog3hjlu hdlP4O3m4hUOfDgRBp9rFHu1TUMqeg== X-Received: by 10.36.88.18 with SMTP id f18mr8936393itb.60.1496984380560; Thu, 08 Jun 2017 21:59:40 -0700 (PDT) MIME-Version: 1.0 References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> In-Reply-To: From: Dick Hardt Date: Fri, 09 Jun 2017 04:59:30 +0000 Message-ID: To: Adam Dawes , "Phil Hunt (IDM)" , "matake, nov" Cc: ID Events Mailing List , Marius Scurtescu Content-Type: multipart/alternative; boundary="001a114064663d006905517fd6b0" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 04:59:44 -0000 --001a114064663d006905517fd6b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yaron, Mike and I just published an BCP ID for JWT http://self-issued.info/?p=3D1690 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes wrote: > I was initially a fan of keeping SETS to be very similar to id tokens but > I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov wrote: > >> +1 especially for "type" >> >> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) : >> >>> +1 >>> >>> Phil >>> >>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >>> wrote: >>> > >>> > There were a couple of proposals on how to distinguish SETs from Id >>> Tokens and Access Tokens in such a way that naive implementations will = not >>> confuse one for the other and open up security vulnerabilities. >>> > >>> > There is also another important requirement: the SET issuer in some >>> cases must be different from the "sub" issuer. This is the case of an R= P >>> sending SETs to an IdP. >>> > >>> > With these requirements in mind I propose the following: >>> > - both "sub" and "iss" to be defined at the event level >>> > - "iss" at event level and at top SET level can be different >>> > - "iss" and "sub" at event level can be different across events in th= e >>> same SET >>> > - "sub" should NOT be present at the top SET level (this solves the >>> disambiguation), please note "should" and not "must" >>> > >>> > This solution also allows different profiles that define event types >>> to define additional claims related to sub (like email or phone_number)= and >>> since all these claims will be at the event level there will be no >>> collisions or ambiguity. >>> > >>> > Another proposal (which I supported) was to define a composite "aud" >>> claim. This is not solving the requirement for a distinct SET issuer. >>> Also, having the same claim name having different syntax in different t= oken >>> types could lead to confusion. >>> > >>> > And yet another proposal was to introduce a new claim for JWTs that >>> defines a "type". This is not practical in the short term, and it also = is >>> not solving the distinct issuer requirement, but I think this is someth= ing >>> the JWT group should seriously consider. >>> > >>> > Thoughts? >>> > >>> > Marius >>> > _______________________________________________ >>> > Id-event mailing list >>> > Id-event@ietf.org >>> > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY= 057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74= AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > -- > Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a114064663d006905517fd6b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yaron, Mike and I just published an BCP ID for JWT=C2=A0http://self-issued.info/?p=3D1690
=

On Thu, Jun 8, 2017 at 9:02 PM Ada= m Dawes <adawes@google.com> = wrote:
I was initially a = fan of keeping SETS to be very similar to id tokens but I now think this is= a better plan.=C2=A0

O= n Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp> wrote:
+1 especially for "type"

2017-06-09 10:32 GMT+09:00 Phil= Hunt (IDM) <phil.hunt@oracle.com>:
+1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <mscurtescu@google.com> wrote:<= br> >
> There were a couple of proposals on how to distinguish SETs from Id To= kens and Access Tokens in such a way that naive implementations will not co= nfuse one for the other and open up security vulnerabilities.
>
> There is also another important requirement: the SET issuer in some ca= ses must be different from the "sub" issuer. This is the case of = an RP sending SETs to an IdP.
>
> With these requirements in mind I propose the following:
> - both "sub" and "iss" to be defined at the event = level
> - "iss" at event level and at top SET level can be different=
> - "iss" and "sub" at event level can be different = across events in the same SET
> - "sub" should NOT be present at the top SET level (this sol= ves the disambiguation), please note "should" and not "must&= quot;
>
> This solution also allows different profiles that define event types t= o define additional claims related to sub (like email or phone_number) and = since all these claims will be at the event level there will be no collisio= ns or ambiguity.
>
> Another proposal (which I supported) was to define a composite "a= ud" claim. This is not solving the requirement for a distinct=C2=A0 SE= T issuer. Also, having the same claim name having different syntax in diffe= rent token types could lead to confusion.
>
> And yet another proposal was to introduce a new claim for JWTs that de= fines a "type". This is not practical in the short term, and it a= lso is not solving the distinct issuer requirement, but I think this is som= ething the JWT group should seriously consider.
>
> Thoughts?
>
> Marius
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&= ;m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwV= qXoVpn88YKOCd0mxPQFJLhxWI&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--
Subscribe to the HARDTWARE mail list to learn about projects I am working on!
--001a114064663d006905517fd6b0-- From nobody Mon Jun 12 15:16:03 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36A12EB6A for ; Mon, 12 Jun 2017 15:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkveiAegUnGZ for ; Mon, 12 Jun 2017 15:15:59 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE0C12EB64 for ; Mon, 12 Jun 2017 15:15:59 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id i7so63215460ioe.1 for ; Mon, 12 Jun 2017 15:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KFWVvPA1btITqsY91co6lYRxIGXCxkXF8LPoM1Iozjg=; b=AaE7Bd1wiVfzMYiEpSQSHBcOpHUJ5PAb9El1bnK9OwpBX2pxMnph72DQSqCgAq/Lpd PHzV+q9vrudPyByfGVbYXwITzhWlfVYwm4DFe1MjNWt1Dp8fz4gkE25nlOYZTuet4FvM lGA6h/+l2HSeBbH98tkazWCNUJE7JMP2ltHtsJ3IXcUcApkzzeZU/yLOJIyk/udI69Aa THUNCW5uU2l2Vl7/Dvz6lbfxejrWlWEWI+umksSZnlEZXd9eL3oYSm+aIZ0KDQAJE/4/ VKe0lMyuIdoLB0iTVPZLdTItkU7iy6DO3yeuH8BblUZZYztsADSigFfJJIjjmUddO0a9 A/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KFWVvPA1btITqsY91co6lYRxIGXCxkXF8LPoM1Iozjg=; b=OvdZezSslr5rK2FzsrFrWBWfrHRxT9e0Uoy3achtKua5vt55REv4khk0qdbyHvolNH 7Oo0+LJjLO98MvQgw1zlCRMEw7OUHzTVbU+tW/9V6PRXq562csH0oPZq2ll+KMmpc6Zd X7Z+MuKfwsQK5jqAFqwshW0MdcPvRnH2lU+f9+A6ak4eNcY+YeEYYwvjxUdDWrH143Ev e9wrpwiVCxKrZlc85X593ZGmjlQJPwvio64SbLjyvOIU0syfgeVcZDKh3il7uSSb54ku w7xFjThYwP1hFZoX/bQgre/jw1XGT+sktRMn51hv9WMTrOv1jmW4qwzkpHTD7weBXFqG 4PKg== X-Gm-Message-State: AODbwcDF4rOsEj9XljZlgOEFsWEu3kGyH/EHXxyZ46T+kbZCrtOXXNhK b1cU8M8znGCe88n9F/+Uo/B/s1EXXosA X-Received: by 10.107.6.7 with SMTP id 7mr19960700iog.122.1497305758346; Mon, 12 Jun 2017 15:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.71 with HTTP; Mon, 12 Jun 2017 15:15:37 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> From: Marius Scurtescu Date: Mon, 12 Jun 2017 15:15:37 -0700 Message-ID: To: Dick Hardt Cc: Adam Dawes , "Phil Hunt (IDM)" , "matake, nov" , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a113fc3eed91b640551caa988" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 22:16:02 -0000 --001a113fc3eed91b640551caa988 Content-Type: text/plain; charset="UTF-8" Thanks for the pointer Dick, very good timing :-) The issue is described by "2.7. Cross-JWT Confusion" and the mitigation is in "3.9. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs", specifically "Use different sets of required claims...", "Use different keys for different kinds of JWTs." and "Use different issuers for different kinds of JWTs.". I still think that a "type" claim would bring a lot of clarity and safety. Marius On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt wrote: > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=1690 > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes wrote: > >> I was initially a fan of keeping SETS to be very similar to id tokens but >> I now think this is a better plan. >> >> On Thu, Jun 8, 2017 at 6:56 PM matake, nov wrote: >> >>> +1 especially for "type" >>> >>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) : >>> >>>> +1 >>>> >>>> Phil >>>> >>>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >>>> wrote: >>>> > >>>> > There were a couple of proposals on how to distinguish SETs from Id >>>> Tokens and Access Tokens in such a way that naive implementations will not >>>> confuse one for the other and open up security vulnerabilities. >>>> > >>>> > There is also another important requirement: the SET issuer in some >>>> cases must be different from the "sub" issuer. This is the case of an RP >>>> sending SETs to an IdP. >>>> > >>>> > With these requirements in mind I propose the following: >>>> > - both "sub" and "iss" to be defined at the event level >>>> > - "iss" at event level and at top SET level can be different >>>> > - "iss" and "sub" at event level can be different across events in >>>> the same SET >>>> > - "sub" should NOT be present at the top SET level (this solves the >>>> disambiguation), please note "should" and not "must" >>>> > >>>> > This solution also allows different profiles that define event types >>>> to define additional claims related to sub (like email or phone_number) and >>>> since all these claims will be at the event level there will be no >>>> collisions or ambiguity. >>>> > >>>> > Another proposal (which I supported) was to define a composite "aud" >>>> claim. This is not solving the requirement for a distinct SET issuer. >>>> Also, having the same claim name having different syntax in different token >>>> types could lead to confusion. >>>> > >>>> > And yet another proposal was to introduce a new claim for JWTs that >>>> defines a "type". This is not practical in the short term, and it also is >>>> not solving the distinct issuer requirement, but I think this is something >>>> the JWT group should seriously consider. >>>> > >>>> > Thoughts? >>>> > >>>> > Marius >>>> > _______________________________________________ >>>> > Id-event mailing list >>>> > Id-event@ietf.org >>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >>>> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c= >>>> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= >>>> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_ >>>> jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >> -- >> Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >> <(650)%20214-2410> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --001a113fc3eed91b640551caa988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the pointer Dick, very good timing :-)

=
The issue is described by "2.7. Cross-JWT Confusion" a= nd the mitigation is in "3.9. Use Mutually Exclusive Validation Rules = for Different Kinds of JWTs", specifically "Use different sets of= required claims...", "Use different keys for different kinds of = JWTs." and "Use different issuers for different kinds of JWTs.&qu= ot;.

I still think that a "type" claim w= ould bring a lot of clarity and safety.

Marius

On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <= span dir=3D"ltr"><dick.hardt@gmail.com> wrote:
Yaron, Mike and I just published an BCP ID for JWT=C2=A0http://self-issued= .info/?p=3D1690

On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com> wrot= e:
I was initially a fan = of keeping SETS to be very similar to id tokens but I now think this is a b= etter plan.=C2=A0

On Th= u, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp> wrote:
+1 especially for "type"

2017-06-09 10:32 GMT+09:00 Phil H= unt (IDM) <phil.hunt@oracle.com>:
+= 1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <mscurtescu@google.com> wrote:<= br> >
> There were a couple of proposals on how to distinguish SETs from Id To= kens and Access Tokens in such a way that naive implementations will not co= nfuse one for the other and open up security vulnerabilities.
>
> There is also another important requirement: the SET issuer in some ca= ses must be different from the "sub" issuer. This is the case of = an RP sending SETs to an IdP.
>
> With these requirements in mind I propose the following:
> - both "sub" and "iss" to be defined at the event = level
> - "iss" at event level and at top SET level can be different=
> - "iss" and "sub" at event level can be different = across events in the same SET
> - "sub" should NOT be present at the top SET level (this sol= ves the disambiguation), please note "should" and not "must&= quot;
>
> This solution also allows different profiles that define event types t= o define additional claims related to sub (like email or phone_number) and = since all these claims will be at the event level there will be no collisio= ns or ambiguity.
>
> Another proposal (which I supported) was to define a composite "a= ud" claim. This is not solving the requirement for a distinct=C2=A0 SE= T issuer. Also, having the same claim name having different syntax in diffe= rent token types could lead to confusion.
>
> And yet another proposal was to introduce a new claim for JWTs that de= fines a "type". This is not practical in the short term, and it a= lso is not solving the distinct issuer requirement, but I think this is som= ething the JWT group should seriously consider.
>
> Thoughts?
>
> Marius
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1= YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkI= TSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvg= Xzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJ= LhxWI&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
Subscribe to the HARDTWARE mail list to learn about projects I am working on= !

--001a113fc3eed91b640551caa988-- From nobody Mon Jun 12 15:19:09 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A38F12EB6A for ; Mon, 12 Jun 2017 15:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yipUj41udpZw for ; Mon, 12 Jun 2017 15:19:05 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB9112EB64 for ; Mon, 12 Jun 2017 15:19:05 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id u12so145965022qth.0 for ; Mon, 12 Jun 2017 15:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SuGAtFw4GTys0fWqLI/DH1U7YVK8l1XV2CXFIKgzT7k=; b=VF1k/+Btalp0qEZrUucv+OubN8UoUKehDAiLtOKSjgvoFVogmo4jVH4w4n5AcTy/Yu wxGScbgDi20RzOLzOHS7dwxulC8D5XZy6Hu5QQZw1eDW8W13RKpWJXF1H+Eddm0lTnWq IpyMgjidM3wONURSX0OzdJhk7b7Xa+6UQC21+TYrOOhf1xRwYED6QCLxmUkB+kS3N8tx IzApYw7hpZEQMaIrlaqzlkbP/3zp9TPUNZwt3R03tDgoSCN2bHOST5Md52/u1Y3ZGTnM iAyc2ATniX1Ra93UPzlzhZByTavhiqotNSLsbpEYcg3VAzr/3oQbp/yV8YHHfOvw2XSy os3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SuGAtFw4GTys0fWqLI/DH1U7YVK8l1XV2CXFIKgzT7k=; b=buRUr6dlPB0uL+pGmVJ0Kl5nHXM9QTY8RtkzMSnqb1B5YL4M+ADUuOCaM3oeatpgg8 ud1kygAsAMKuTxkMTamivdOxKkllQCZmGFlbRlQ0TqQF8dM8rUWz6gsR34DeZ/TmyPuK LG9RPzca5tARW7eGRvwb0jvXvtkyYAkeLMLM7SenQFBjEjU2GuIGbyeazFiSrwpsihFG PUlD1z8wpWsOhrWJOdJ5M3W5Cw31Ml8Fcct0hAQNZJoT0YITj3DJF+SBa5yQJP7O4Qd8 tbCjkW8W7umsA6wQsjaSofez+St6qUp9VIt6sqqOzU5qH9z7yMpKgkl4480QAOOU1J9Q vHPw== X-Gm-Message-State: AKS2vOy16XjfgmcQ1Yplssdnejyy4bZU4OEcaiThHANsjX3dso6uUJAX bCYY7vDTgY7O0s5uAxdiNpMH/SJazA== X-Received: by 10.200.53.193 with SMTP id l1mr53583139qtb.7.1497305944471; Mon, 12 Jun 2017 15:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.92.245 with HTTP; Mon, 12 Jun 2017 15:18:43 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> From: Dick Hardt Date: Mon, 12 Jun 2017 15:18:43 -0700 Message-ID: To: Marius Scurtescu Cc: Adam Dawes , "Phil Hunt (IDM)" , "matake, nov" , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a114096acf0c89a0551cab47c" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 22:19:08 -0000 --001a114096acf0c89a0551cab47c Content-Type: text/plain; charset="UTF-8" Agreed. Note that there is still lots of discussion on what should be in 3.9. On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu wrote: > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the mitigation is > in "3.9. Use Mutually Exclusive Validation Rules for Different Kinds of > JWTs", specifically "Use different sets of required claims...", "Use > different keys for different kinds of JWTs." and "Use different issuers for > different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and safety. > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt wrote: > >> Yaron, Mike and I just published an BCP ID for JWT >> http://self-issued.info/?p=1690 >> >> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes wrote: >> >>> I was initially a fan of keeping SETS to be very similar to id tokens >>> but I now think this is a better plan. >>> >>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov wrote: >>> >>>> +1 especially for "type" >>>> >>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) : >>>> >>>>> +1 >>>>> >>>>> Phil >>>>> >>>>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >>>>> wrote: >>>>> > >>>>> > There were a couple of proposals on how to distinguish SETs from Id >>>>> Tokens and Access Tokens in such a way that naive implementations will not >>>>> confuse one for the other and open up security vulnerabilities. >>>>> > >>>>> > There is also another important requirement: the SET issuer in some >>>>> cases must be different from the "sub" issuer. This is the case of an RP >>>>> sending SETs to an IdP. >>>>> > >>>>> > With these requirements in mind I propose the following: >>>>> > - both "sub" and "iss" to be defined at the event level >>>>> > - "iss" at event level and at top SET level can be different >>>>> > - "iss" and "sub" at event level can be different across events in >>>>> the same SET >>>>> > - "sub" should NOT be present at the top SET level (this solves the >>>>> disambiguation), please note "should" and not "must" >>>>> > >>>>> > This solution also allows different profiles that define event types >>>>> to define additional claims related to sub (like email or phone_number) and >>>>> since all these claims will be at the event level there will be no >>>>> collisions or ambiguity. >>>>> > >>>>> > Another proposal (which I supported) was to define a composite "aud" >>>>> claim. This is not solving the requirement for a distinct SET issuer. >>>>> Also, having the same claim name having different syntax in different token >>>>> types could lead to confusion. >>>>> > >>>>> > And yet another proposal was to introduce a new claim for JWTs that >>>>> defines a "type". This is not practical in the short term, and it also is >>>>> not solving the distinct issuer requirement, but I think this is something >>>>> the JWT group should seriously consider. >>>>> > >>>>> > Thoughts? >>>>> > >>>>> > Marius >>>>> > _______________________________________________ >>>>> > Id-event mailing list >>>>> > Id-event@ietf.org >>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv >>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz >>>>> jWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqm >>>>> g&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>> -- >>> Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >>> <(650)%20214-2410> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >> -- >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> > > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a114096acf0c89a0551cab47c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. Note that there is still lots of discussion on wha= t should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@= google.com> wrote:
Thanks for the pointer Dick, very good timing :-)

The issue is described by "2.7. Cross-JWT Confusion" and the m= itigation is in "3.9. Use Mutually Exclusive Validation Rules for Diff= erent Kinds of JWTs", specifically "Use different sets of require= d claims...", "Use different keys for different kinds of JWTs.&qu= ot; and "Use different issuers for different kinds of JWTs.".

I still think that a "type" claim would bri= ng a lot of clarity and safety.

Marius

On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <= span dir=3D"ltr"><dick.hardt@gmail.com> wrote:
Yaron, Mike and I just published an BCP ID for JWT=C2=A0http://self-issued= .info/?p=3D1690
=

On Thu, Jun 8, 2017 at 9:02 PM Ada= m Dawes <adawes@g= oogle.com> wrote:
I was initially a fan of keeping SETS to be very similar to id tokens but= I now think this is a better plan.=C2=A0

On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp> wrote:
+1 especially for "type&quo= t;

2017-06-0= 9 10:32 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
+1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <mscurtescu@google.com> wrote:<= br> >
> There were a couple of proposals on how to distinguish SETs from Id To= kens and Access Tokens in such a way that naive implementations will not co= nfuse one for the other and open up security vulnerabilities.
>
> There is also another important requirement: the SET issuer in some ca= ses must be different from the "sub" issuer. This is the case of = an RP sending SETs to an IdP.
>
> With these requirements in mind I propose the following:
> - both "sub" and "iss" to be defined at the event = level
> - "iss" at event level and at top SET level can be different=
> - "iss" and "sub" at event level can be different = across events in the same SET
> - "sub" should NOT be present at the top SET level (this sol= ves the disambiguation), please note "should" and not "must&= quot;
>
> This solution also allows different profiles that define event types t= o define additional claims related to sub (like email or phone_number) and = since all these claims will be at the event level there will be no collisio= ns or ambiguity.
>
> Another proposal (which I supported) was to define a composite "a= ud" claim. This is not solving the requirement for a distinct=C2=A0 SE= T issuer. Also, having the same claim name having different syntax in diffe= rent token types could lead to confusion.
>
> And yet another proposal was to introduce a new claim for JWTs that de= fines a "type". This is not practical in the short term, and it a= lso is not solving the distinct issuer requirement, but I think this is som= ething the JWT group should seriously consider.
>
> Thoughts?
>
> Marius
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.o= rg
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet<= wbr>f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCX= CgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJ= xPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiH= qWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&= e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
Subscribe to the HARDTWARE mail list to learn about projects I am working on= !




--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
--001a114096acf0c89a0551cab47c-- From nobody Mon Jun 12 16:06:29 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C43128799 for ; Mon, 12 Jun 2017 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.301 X-Spam-Level: X-Spam-Status: No, score=-17.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRsmQM8VapRW for ; Mon, 12 Jun 2017 16:06:25 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE6C126CC7 for ; Mon, 12 Jun 2017 16:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1497308785; x=1528844785; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MsOj0r+7kV4S1JjwQR/ojHg9hh2H58n0HFDJ1WRzxlA=; b=sxba5P6MYjB1lIKRDPTHXTUzHbk7nlsj/UPtkkTVSOnVpeC7fpyhAtqv sNf74bZ4J54JVaiZDLlaF61FLlxbUtl5Kr06CfVGIhAg9FiUrUumpj5dd 6CbiF17zD+8V6K8sZcPsC2TZqXdrxRPyBO0QeLGszpe7SI6XU4+DQIunp w=; X-IronPort-AV: E=Sophos;i="5.39,335,1493683200"; d="scan'208,217";a="687251174" Received: from sea19-co-svc-lb5-vlan2.sea.amazon.com (HELO email-inbound-relay-62008.pdx2.amazon.com) ([10.47.22.162]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jun 2017 23:04:46 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-62008.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP id v5CN1iTT009050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Jun 2017 23:01:46 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Jun 2017 23:01:45 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Jun 2017 23:01:44 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Mon, 12 Jun 2017 23:01:44 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Marius Scurtescu CC: Adam Dawes , "matake, nov" , "ID Events Mailing List" , "Phil Hunt (IDM)" Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwA Date: Mon, 12 Jun 2017 23:01:44 +0000 Message-ID: <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.145] Content-Type: multipart/alternative; boundary="_000_1EE56A12E2A2400DA5618C6818C8BAA9amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:06:28 -0000 --_000_1EE56A12E2A2400DA5618C6818C8BAA9amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsgdGhlIGFzc3VtcHRp b25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCtyAgICAgICAgIFdlIGNhbuKAmXQg Z3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhj bHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQg ZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFp beKAnSBhcHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBj YW7igJl0IGJlIG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3ICAg ICAgICAgSXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUg dG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBy dWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdp bGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1h bmFnaW5nIE4gZGlmZmVyZW50IGtleXMuDQoNCsK3ICAgICAgICAgRGl0dG8gZm9yIOKAnGF1ZOKA nSBhbmQg4oCcaXNz4oCdIGNsYWltcy4NCg0KKzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2Fn ZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1ldGVyLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPg0KRGF0ZTogTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NClRvOiBNYXJpdXMg U2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb20+DQpDYzogQWRhbSBEYXdlcyA8YWRhd2Vz QGdvb2dsZS5jb20+LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPiwgSUQgRXZlbnRzIE1h aWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5o dW50QG9yYWNsZS5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQv QWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpBZ3JlZWQu IE5vdGUgdGhhdCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hhdCBzaG91 bGQgYmUgaW4gMy45Lg0KDQpPbiBNb24sIEp1biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMg U2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xl LmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2ZXJ5IGdvb2QgdGlt aW5nIDotKQ0KDQpUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICIyLjcuIENyb3NzLUpXVCBDb25m dXNpb24iIGFuZCB0aGUgbWl0aWdhdGlvbiBpcyBpbiAiMy45LiBVc2UgTXV0dWFsbHkgRXhjbHVz aXZlIFZhbGlkYXRpb24gUnVsZXMgZm9yIERpZmZlcmVudCBLaW5kcyBvZiBKV1RzIiwgc3BlY2lm aWNhbGx5ICJVc2UgZGlmZmVyZW50IHNldHMgb2YgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBk aWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuIiBhbmQgIlVzZSBkaWZm ZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuIi4NCg0KSSBzdGlsbCB0 aGluayB0aGF0IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5k IHNhZmV0eS4NCg0KTWFyaXVzDQoNCk9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwgRGlj ayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t Pj4gd3JvdGU6DQpZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9y IEpXVCBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkwDQoNCk9uIFRodSwgSnVuIDgsIDIw MTcgYXQgOTowMiBQTSBBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2Vz QGdvb2dsZS5jb20+PiB3cm90ZToNCkkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNF VFMgdG8gYmUgdmVyeSBzaW1pbGFyIHRvIGlkIHRva2VucyBidXQgSSBub3cgdGhpbmsgdGhpcyBp cyBhIGJldHRlciBwbGFuLg0KDQpPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtl LCBub3YgPG5vdkBtYXRha2UuanA8bWFpbHRvOm5vdkBtYXRha2UuanA+PiB3cm90ZToNCisxIGVz cGVjaWFsbHkgZm9yICJ0eXBlIg0KDQoyMDE3LTA2LTA5IDEwOjMyIEdNVCswOTowMCBQaGlsIEh1 bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bT4+Og0KKzENCg0KUGhpbA0KDQo+IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMg U2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xl LmNvbT4+IHdyb3RlOg0KPg0KPiBUaGVyZSB3ZXJlIGEgY291cGxlIG9mIHByb3Bvc2FscyBvbiBo b3cgdG8gZGlzdGluZ3Vpc2ggU0VUcyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBp biBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90IGNvbmZ1c2Ug b25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVzLg0K Pg0KPiBUaGVyZSBpcyBhbHNvIGFub3RoZXIgaW1wb3J0YW50IHJlcXVpcmVtZW50OiB0aGUgU0VU IGlzc3VlciBpbiBzb21lIGNhc2VzIG11c3QgYmUgZGlmZmVyZW50IGZyb20gdGhlICJzdWIiIGlz c3Vlci4gVGhpcyBpcyB0aGUgY2FzZSBvZiBhbiBSUCBzZW5kaW5nIFNFVHMgdG8gYW4gSWRQLg0K Pg0KPiBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGUgZm9sbG93 aW5nOg0KPiAtIGJvdGggInN1YiIgYW5kICJpc3MiIHRvIGJlIGRlZmluZWQgYXQgdGhlIGV2ZW50 IGxldmVsDQo+IC0gImlzcyIgYXQgZXZlbnQgbGV2ZWwgYW5kIGF0IHRvcCBTRVQgbGV2ZWwgY2Fu IGJlIGRpZmZlcmVudA0KPiAtICJpc3MiIGFuZCAic3ViIiBhdCBldmVudCBsZXZlbCBjYW4gYmUg ZGlmZmVyZW50IGFjcm9zcyBldmVudHMgaW4gdGhlIHNhbWUgU0VUDQo+IC0gInN1YiIgc2hvdWxk IE5PVCBiZSBwcmVzZW50IGF0IHRoZSB0b3AgU0VUIGxldmVsICh0aGlzIHNvbHZlcyB0aGUgZGlz YW1iaWd1YXRpb24pLCBwbGVhc2Ugbm90ZSAic2hvdWxkIiBhbmQgbm90ICJtdXN0Ig0KPg0KPiBU aGlzIHNvbHV0aW9uIGFsc28gYWxsb3dzIGRpZmZlcmVudCBwcm9maWxlcyB0aGF0IGRlZmluZSBl dmVudCB0eXBlcyB0byBkZWZpbmUgYWRkaXRpb25hbCBjbGFpbXMgcmVsYXRlZCB0byBzdWIgKGxp a2UgZW1haWwgb3IgcGhvbmVfbnVtYmVyKSBhbmQgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3aWxs IGJlIGF0IHRoZSBldmVudCBsZXZlbCB0aGVyZSB3aWxsIGJlIG5vIGNvbGxpc2lvbnMgb3IgYW1i aWd1aXR5Lg0KPg0KPiBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRv IGRlZmluZSBhIGNvbXBvc2l0ZSAiYXVkIiBjbGFpbS4gVGhpcyBpcyBub3Qgc29sdmluZyB0aGUg cmVxdWlyZW1lbnQgZm9yIGEgZGlzdGluY3QgIFNFVCBpc3N1ZXIuIEFsc28sIGhhdmluZyB0aGUg c2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4IGluIGRpZmZlcmVudCB0b2tl biB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi4NCj4NCj4gQW5kIHlldCBhbm90aGVyIHBy b3Bvc2FsIHdhcyB0byBpbnRyb2R1Y2UgYSBuZXcgY2xhaW0gZm9yIEpXVHMgdGhhdCBkZWZpbmVz IGEgInR5cGUiLiBUaGlzIGlzIG5vdCBwcmFjdGljYWwgaW4gdGhlIHNob3J0IHRlcm0sIGFuZCBp dCBhbHNvIGlzIG5vdCBzb2x2aW5nIHRoZSBkaXN0aW5jdCBpc3N1ZXIgcmVxdWlyZW1lbnQsIGJ1 dCBJIHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIHRoZSBKV1QgZ3JvdXAgc2hvdWxkIHNlcmlvdXNs eSBjb25zaWRlci4NCj4NCj4gVGhvdWdodHM/DQo+DQo+IE1hcml1cw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZC1ldmVudCBtYWlsaW5nIGxp c3QNCj4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KPiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZtPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlI cVdnZnhxbWcmcz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmU9 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1l dmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50 IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KLS0NCkFk YW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHwgYWRhd2VzQGdvb2dsZS5jb208bWFpbHRv OmFkYXdlc0Bnb29nbGUuY29tPiB8ICsxIDY1MC0yMTQtMjQxMDx0ZWw6KDY1MCklMjAyMTQtMjQx MD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklk LWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0K LS0NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFp bCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCg0K LS0NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFp bCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg== --_000_1EE56A12E2A2400DA5618C6818C8BAA9amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFu LmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ Y29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDo5MzUwMTY1NDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NTQ4MTY2MDQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+SSB0aGluayB0aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQgaW4gMy45IGFyZSBmbGF3 ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPldlIGNh buKAmXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFs bHkgZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJz LCBhbmQgZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXpl ZCBjbGFpbeKAnQ0KIGFwcHJvYWNoIHRvIGVuc3VyZSB0aGF0IEpXVHMgZnJvbSBzb21lIGZ1dHVy ZSBzcGVjIGNhbuKAmXQgYmUgbWlzdGFrZW4gZm9yIEpXVHMgZnJvbSBhIGN1cnJlbnQgc3BlYy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SXQgaXMgdW5y ZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZl cmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1h bmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMN CiBiZWNhdXNlIG1hbmFnaW5nIG9uZSBrZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZm ZXJlbnQga2V5cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mIzQzOzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFp bS9oZWFkZXIgcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWRl bnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+SWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFs ZiBvZiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+TW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE08YnI+DQo8Yj5UbzogPC9iPk1h cml1cyBTY3VydGVzY3UgJmx0O21zY3VydGVzY3VAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPkFkYW0gRGF3ZXMgJmx0O2FkYXdlc0Bnb29nbGUuY29tJmd0OywgJnF1b3Q7bWF0YWtlLCBu b3YmcXVvdDsgJmx0O25vdkBtYXRha2UuanAmZ3Q7LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZs dDtpZC1ldmVudEBpZXRmLm9yZyZndDssICZxdW90O1BoaWwgSHVudCAoSURNKSZxdW90OyAmbHQ7 cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BZ3JlZWQuIE5vdGUgdGhhdCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRp c2N1c3Npb24gb24gd2hhdCBzaG91bGQgYmUgaW4gMy45LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMTIsIDIwMTcgYXQgMzoxNSBQTSwg TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MgZm9yIHRoZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlIGlzIGRlc2Ny aWJlZCBieSAmcXVvdDsyLjcuIENyb3NzLUpXVCBDb25mdXNpb24mcXVvdDsgYW5kIHRoZSBtaXRp Z2F0aW9uIGlzIGluICZxdW90OzMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2ZSBWYWxpZGF0aW9u IFJ1bGVzIGZvciBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyZxdW90Oywgc3BlY2lmaWNhbGx5ICZx dW90O1VzZSBkaWZmZXJlbnQgc2V0cyBvZiByZXF1aXJlZCBjbGFpbXMuLi4mcXVvdDssICZxdW90 O1VzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50DQoga2luZHMgb2YgSldUcy4mcXVvdDsg YW5kICZxdW90O1VzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpX VHMuJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHN0aWxsIHRoaW5rIHRoYXQgYSAmcXVvdDt0eXBlJnF1b3Q7IGNsYWltIHdvdWxk IGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kIHNhZmV0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxiciBjbGVhcj0iYWxsIj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iaG9lbnpiIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPk1hcml1czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwg RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWFyb24sIE1p a2UgYW5kIEkganVzdCBwdWJsaXNoZWQgYW4gQkNQIElEIGZvciBKV1QmbmJzcDs8YSBocmVmPSJo dHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Nl bGYtaXNzdWVkLmluZm8vP3A9MTY5MDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDgsIDIwMTcg YXQgOTowMiBQTSBBZGFtIERhd2VzICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdhcyBpbml0aWFsbHkgYSBmYW4gb2Yga2VlcGluZyBTRVRTIHRvIGJlIHZl cnkgc2ltaWxhciB0byBpZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIg cGxhbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBtYXRha2UsIG5v diAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5rIj5ub3ZA bWF0YWtlLmpwPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIGVzcGVjaWFsbHkgZm9yICZx dW90O3R5cGUmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIwMTctMDYtMDkgMTA6MzIgR01UJiM0MzswOTowMCBQaGlsIEh1bnQgKElETSkgJmx0Ozxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IE9uIEp1biA4LCAy MDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNj dXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUgd2VyZSBhIGNvdXBsZSBv ZiBwcm9wb3NhbHMgb24gaG93IHRvIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5k IEFjY2VzcyBUb2tlbnMgaW4gc3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3 aWxsIG5vdCBjb25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5IHZ1 bG5lcmFiaWxpdGllcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBpcyBhbHNvIGFub3RoZXIg aW1wb3J0YW50IHJlcXVpcmVtZW50OiB0aGUgU0VUIGlzc3VlciBpbiBzb21lIGNhc2VzIG11c3Qg YmUgZGlmZmVyZW50IGZyb20gdGhlICZxdW90O3N1YiZxdW90OyBpc3N1ZXIuIFRoaXMgaXMgdGhl IGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzIHRvIGFuIElkUC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5n Ojxicj4NCiZndDsgLSBib3RoICZxdW90O3N1YiZxdW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7IHRv IGJlIGRlZmluZWQgYXQgdGhlIGV2ZW50IGxldmVsPGJyPg0KJmd0OyAtICZxdW90O2lzcyZxdW90 OyBhdCBldmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBsZXZlbCBjYW4gYmUgZGlmZmVyZW50PGJy Pg0KJmd0OyAtICZxdW90O2lzcyZxdW90OyBhbmQgJnF1b3Q7c3ViJnF1b3Q7IGF0IGV2ZW50IGxl dmVsIGNhbiBiZSBkaWZmZXJlbnQgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ8YnI+DQom Z3Q7IC0gJnF1b3Q7c3ViJnF1b3Q7IHNob3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNF VCBsZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUgJnF1 b3Q7c2hvdWxkJnF1b3Q7IGFuZCBub3QgJnF1b3Q7bXVzdCZxdW90Ozxicj4NCiZndDs8YnI+DQom Z3Q7IFRoaXMgc29sdXRpb24gYWxzbyBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQgZGVm aW5lIGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltcyByZWxhdGVkIHRvIHN1 YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFuZCBzaW5jZSBhbGwgdGhlc2UgY2xhaW1z IHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxldmVsIHRoZXJlIHdpbGwgYmUgbm8gY29sbGlzaW9ucyBv ciBhbWJpZ3VpdHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5vdGhlciBwcm9wb3NhbCAod2hpY2gg SSBzdXBwb3J0ZWQpIHdhcyB0byBkZWZpbmUgYSBjb21wb3NpdGUgJnF1b3Q7YXVkJnF1b3Q7IGNs YWltLiBUaGlzIGlzIG5vdCBzb2x2aW5nIHRoZSByZXF1aXJlbWVudCBmb3IgYSBkaXN0aW5jdCZu YnNwOyBTRVQgaXNzdWVyLiBBbHNvLCBoYXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcg ZGlmZmVyZW50IHN5bnRheCBpbiBkaWZmZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBj b25mdXNpb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kIHlldCBhbm90aGVyIHByb3Bvc2FsIHdh cyB0byBpbnRyb2R1Y2UgYSBuZXcgY2xhaW0gZm9yIEpXVHMgdGhhdCBkZWZpbmVzIGEgJnF1b3Q7 dHlwZSZxdW90Oy4gVGhpcyBpcyBub3QgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQg aXQgYWxzbyBpcyBub3Qgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBi dXQgSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNob3VsZCBzZXJpb3Vz bHkgY29uc2lkZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhvdWdodHM/PGJyPg0KJmd0Ozxicj4N CiZndDsgTWFyaXVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1w O3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7 ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDtt PUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1wO3M9NXhRcXZC aVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT08L2E+PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZl bnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi10b3A6Ny41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtj b2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjRDUwRjI1IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPkFk YW0gRGF3ZXMmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7 Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzMzNjlFOCAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4m bmJzcDtTci4gUHJvZHVjdA0KIE1hbmFnZXImbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzAwOTkzOSAxLjVw dDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mbmJzcDt8PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQg I0VFQjIxMSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDs8YSBocmVmPSJ0ZWw6KDY1MCklMjAy MTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7MQ0KIDY1MC0yMTQtMjQxMDwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojNTU1NTU1Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U3Vic2NyaWJlIHRvIHRoZSA8YSBocmVmPSJodHRwOi8vaGFyZHR3YXJlLmNvbS8iIHRhcmdldD0i X2JsYW5rIj4NCkhBUkRUV0FSRTwvYT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3Rz IEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YnNjcmliZSB0byB0aGUgPGEgaHJlZj0iaHR0cDovL2hh cmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+DQpIQVJEVFdBUkU8L2E+IG1haWwgbGlzdCB0 byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1EE56A12E2A2400DA5618C6818C8BAA9amazoncom_-- From nobody Tue Jun 13 02:15:53 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09F12EC0E for ; Tue, 13 Jun 2017 02:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycza9aKmAlqh for ; Tue, 13 Jun 2017 02:15:49 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AD312EC62 for ; Tue, 13 Jun 2017 02:10:02 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5D99vDo005259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Jun 2017 11:09:59 +0200 Received: from [192.168.55.156] (62.96.251.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 13 Jun 2017 11:09:52 +0200 To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> From: Henk Birkholz Message-ID: <2bb03913-cade-0795-bd99-45a048a6957e@sit.fraunhofer.de> Date: Tue, 13 Jun 2017 11:09:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [62.96.251.245] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:15:52 -0000 Hello, quick question. Are you thinking about a more traditional content-type or an information-type as can be found in: > https://tools.ietf.org/html/draft-ietf-mile-rolie-07#section-7.1.2 Viele Grüße, Henk On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > ·We can’t guarantee that every type of JWT will have a mutually > exclusive set of valid claims and/or header parameters, and enforcing > this requires a “fail on an unrecognized claim” approach to ensure that > JWTs from some future spec can’t be mistaken for JWTs from a current spec. > > ·It is unrealistic to expect implementers to adhere to the “different > keys for different kinds of JWTs” rule. Whether mandated by the spec or > not, implementers will ignore this because managing one key is easier > than managing N different keys. > > ·Ditto for “aud” and “iss” claims. > > +1 for a “type” or “usage” claim/header parameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt > > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=1690 > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > -- > > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > -- > > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Tue Jun 13 02:18:49 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E861314A6 for ; Tue, 13 Jun 2017 02:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxcODIPqPewl for ; Tue, 13 Jun 2017 02:18:43 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2588312EC82 for ; Tue, 13 Jun 2017 02:11:36 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5D9BYnc005378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Jun 2017 11:11:35 +0200 Received: from [192.168.55.156] (62.96.251.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 13 Jun 2017 11:11:29 +0200 To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> From: Henk Birkholz Message-ID: <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> Date: Tue, 13 Jun 2017 11:11:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [62.96.251.245] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:18:47 -0000 And a 2nd question. What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"? Henk On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > ·We can’t guarantee that every type of JWT will have a mutually > exclusive set of valid claims and/or header parameters, and enforcing > this requires a “fail on an unrecognized claim” approach to ensure that > JWTs from some future spec can’t be mistaken for JWTs from a current spec. > > ·It is unrealistic to expect implementers to adhere to the “different > keys for different kinds of JWTs” rule. Whether mandated by the spec or > not, implementers will ignore this because managing one key is easier > than managing N different keys. > > ·Ditto for “aud” and “iss” claims. > > +1 for a “type” or “usage” claim/header parameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt > > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=1690 > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > -- > > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > -- > > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Tue Jun 13 09:19:21 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BCB131A87 for ; Tue, 13 Jun 2017 09:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY7oVLP6Qr30 for ; Tue, 13 Jun 2017 09:19:15 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7C2131B2B for ; Tue, 13 Jun 2017 09:12:04 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5DGC2Kx028120 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Jun 2017 16:12:03 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5DGC2Jl024499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jun 2017 16:12:02 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5DGBxxj027782; Tue, 13 Jun 2017 16:12:00 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Jun 2017 09:11:58 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> Date: Tue, 13 Jun 2017 09:11:56 -0700 Cc: id-event@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8412C6B8-E0AB-49C2-BE03-2EF222DC3CED@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> To: Henk Birkholz X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:19:18 -0000 Yes and no. We have an event type uri attribute that indicates content. It d= efines the type of event and enables a payload json object to be attached.=20= IOW, SET's type Works differently.=20 Phil > On Jun 13, 2017, at 2:11 AM, Henk Birkholz wrote: >=20 > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via "intend= ", "audience", and "scope"? >=20 > Henk >=20 >> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >> Thanks for putting this together! >> I think the assumptions inherent in 3.9 are flawed: >> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive set of valid claims and/or header parameters, and enforcing th= is requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from= a current spec. >> =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys for different kinds of JWTs=E2=80=9D rule. Whether mandated b= y the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys. >> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. >> --=20 >> Annabelle Richard Backman >> Identity Services >> *From: *Id-event on behalf of Dick Hardt >> *Date: *Monday, June 12, 2017 at 3:18 PM >> *To: *Marius Scurtescu >> *Cc: *Adam Dawes , "matake, nov" , ID E= vents Mailing List , "Phil Hunt (IDM)" >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and dist= inct SET issuer >> Agreed. Note that there is still lots of discussion on what should be in 3= .9. >> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >> Thanks for the pointer Dick, very good timing :-) >> The issue is described by "2.7. Cross-JWT Confusion" and the >> mitigation is in "3.9. Use Mutually Exclusive Validation Rules for >> Different Kinds of JWTs", specifically "Use different sets of >> required claims...", "Use different keys for different kinds of >> JWTs." and "Use different issuers for different kinds of JWTs.". >> I still think that a "type" claim would bring a lot of clarity and >> safety. >> Marius >> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > > wrote: >> Yaron, Mike and I just published an BCP ID for JWT >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__self-2Dissue= d.info_-3Fp-3D1690&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D24GdxYmg1CIzVq_K__5ina= EWYG6ZrWzxu2Gu6_gAJ-0&s=3DTmPWehBYcEv9H3-5mfe8VNG0PBvicrwhiIHAjmjxXPk&e=3D = On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > > wrote: >> I was initially a fan of keeping SETS to be very similar to >> id tokens but I now think this is a better plan. >> On Thu, Jun 8, 2017 at 6:56 PM matake, nov > > wrote: >> +1 especially for "type" >> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >> >: >> +1 >> Phil >> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> > > wrote: >> > >> > There were a couple of proposals on how to >> distinguish SETs from Id Tokens and Access Tokens in >> such a way that naive implementations will not >> confuse one for the other and open up security >> vulnerabilities. >> > >> > There is also another important requirement: the >> SET issuer in some cases must be different from the >> "sub" issuer. This is the case of an RP sending SETs >> to an IdP. >> > >> > With these requirements in mind I propose the >> following: >> > - both "sub" and "iss" to be defined at the event >> level >> > - "iss" at event level and at top SET level can >> be different >> > - "iss" and "sub" at event level can be different >> across events in the same SET >> > - "sub" should NOT be present at the top SET >> level (this solves the disambiguation), please note >> "should" and not "must" >> > >> > This solution also allows different profiles that >> define event types to define additional claims >> related to sub (like email or phone_number) and >> since all these claims will be at the event level >> there will be no collisions or ambiguity. >> > >> > Another proposal (which I supported) was to >> define a composite "aud" claim. This is not solving >> the requirement for a distinct SET issuer. Also, >> having the same claim name having different syntax >> in different token types could lead to confusion. >> > >> > And yet another proposal was to introduce a new >> claim for JWTs that defines a "type". This is not >> practical in the short term, and it also is not >> solving the distinct issuer requirement, but I think >> this is something the JWT group should seriously >> consider. >> > >> > Thoughts? >> > >> > Marius >> > _______________________________________________ >> > Id-event mailing list >> > Id-event@ietf.org >> > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YK= OCd0mxPQFJLhxWI&e=3D >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= 24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=3DfA3RYdeEvTH-Q-h8EvUi4V7WR6Zf= siWdesV5yKZNS_Y&e=3D _______________________________________= ________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ietf.org_mailman_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D24G= dxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=3DfA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiW= desV5yKZNS_Y&e=3D -- Adam Dawes | Sr. Product Manage= r |adawes@google.com >> |+1 650-214-2410 >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D24GdxYm= g1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=3DfA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV= 5yKZNS_Y&e=3D -- Subscribe to the HARDTWARE mail list to >> learn about projects I am working on! >> --=20 >> Subscribe to the HARDTWARE mail list to learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057= SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D24GdxYmg1CIzVq_K__= 5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=3DfA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e=3D= =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D24GdxYmg1CIzVq_K__5= inaEWYG6ZrWzxu2Gu6_gAJ-0&s=3DfA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e=3D= =20 From nobody Tue Jun 13 11:05:42 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE1512954C for ; Tue, 13 Jun 2017 11:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tt-AW_DmLGm for ; Tue, 13 Jun 2017 11:05:37 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BF1129464 for ; Tue, 13 Jun 2017 11:05:36 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id k93so78531796ioi.2 for ; Tue, 13 Jun 2017 11:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nhp9HfwDenAZsntaf2o9vSE+s0ne1XJr3luaEmSWt6I=; b=o+peqwH/dTfGWqjkcTvulH5FTmjwSFOyaeRorcv1T1g6NMtHPBZ+rtkQ4HlsbS2QU/ g1QdXWKhWT8R+O/e1AI5oAQHDoIYh3gJ2UdQ1CE2zF8xopokQOJypcTzpkpXtNtRJ9l1 QlAJfpmzsfUfRgYV79oUBebaqs+/PErc6bemE9RrFfajE7GvXwvpjWoJolwYV4FL5171 UncEGJEdnk3SjOXpzH9NRbsHFP2JrDkkJwTSYtczSPEWomJ/hu8XVMNepY+wJm+v5R64 IP/qbTE2CaewBlbs+2IPhxo6FvG2ofGVSAm1Jc/Ox3aGneVEXaP4tUxmKYdCCRrDdxv4 1/Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nhp9HfwDenAZsntaf2o9vSE+s0ne1XJr3luaEmSWt6I=; b=rPcWmkjQYx3VL3BVP3Wa8tf0P1Zg2Pjz2JiG+q7CYRXAlZ+4aSq7FBg/y8vgrFvMks d48F2dZe32RFX8CwZD7IbfXEB8QmevtjbG8h3+Hake6su50qk02dVOD91fBN7Rz6g2P4 49R3/5qlaGVxgfK/R1jEnN6f0/0LPLpznbZKlSzUxKlbiWpEGzjqc5U9Thhol8TUAsI7 vW/k183ptVmd7qhI/+VvwNBP/MphvIHOHiuvCI4g0Heiso+DY5wa2sXx/E0UJYmyHz8f /6KmBch3YDXv0n1h2Bpd95ZVvWRsdcrjnEtANBHOoK6mK1MEvW0FvEjplkbaU3JR2PqQ HpgA== X-Gm-Message-State: AKS2vOxnf4bSNTmybWW/nR3tloZosrVBVK8ID+JBpoEEA8sJJ8Hou7cN KWC/ooinu4sNJMCYq6DmIxoje0qwIw3VGpo= X-Received: by 10.107.18.16 with SMTP id a16mr1451554ioj.93.1497377135564; Tue, 13 Jun 2017 11:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.71 with HTTP; Tue, 13 Jun 2017 11:05:15 -0700 (PDT) In-Reply-To: <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> From: Marius Scurtescu Date: Tue, 13 Jun 2017 11:05:15 -0700 Message-ID: To: Henk Birkholz Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a113ee31e4324a80551db48f0" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:05:41 -0000 --001a113ee31e4324a80551db48f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < henk.birkholz@sit.fraunhofer.de> wrote: > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? "aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?) "scope" is not used by SET. I don't know what do you mean by "intend" (or intent)? > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > >> Thanks for putting this together! >> >> I think the assumptions inherent in 3.9 are flawed: >> >> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutu= ally exclusive >> set of valid claims and/or header parameters, and enforcing this require= s a >> =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that = JWTs from some >> future spec can=E2=80=99t be mistaken for JWTs from a current spec. >> >> =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80= =9Cdifferent >> keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by the = spec or >> not, implementers will ignore this because managing one key is easier th= an >> managing N different keys. >> >> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >> >> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter. >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> *From: *Id-event on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Monday, June 12, 2017 at 3:18 PM >> *To: *Marius Scurtescu >> *Cc: *Adam Dawes , "matake, nov" , ID >> Events Mailing List , "Phil Hunt (IDM)" < >> phil.hunt@oracle.com> >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> Agreed. Note that there is still lots of discussion on what should be in >> 3.9. >> >> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > > wrote: >> >> Thanks for the pointer Dick, very good timing :-) >> >> The issue is described by "2.7. Cross-JWT Confusion" and the >> mitigation is in "3.9. Use Mutually Exclusive Validation Rules for >> Different Kinds of JWTs", specifically "Use different sets of >> required claims...", "Use different keys for different kinds of >> JWTs." and "Use different issuers for different kinds of JWTs.". >> >> I still think that a "type" claim would bring a lot of clarity and >> safety. >> >> >> Marius >> >> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > > wrote: >> >> Yaron, Mike and I just published an BCP ID for JWT >> http://self-issued.info/?p=3D1690 >> >> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > > wrote: >> >> I was initially a fan of keeping SETS to be very similar to >> id tokens but I now think this is a better plan. >> >> On Thu, Jun 8, 2017 at 6:56 PM matake, nov > > wrote: >> >> +1 especially for "type" >> >> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >> >: >> >> +1 >> >> Phil >> >> >> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> > > wrote: >> > >> > There were a couple of proposals on how to >> distinguish SETs from Id Tokens and Access Tokens in >> such a way that naive implementations will not >> confuse one for the other and open up security >> vulnerabilities. >> > >> > There is also another important requirement: the >> SET issuer in some cases must be different from the >> "sub" issuer. This is the case of an RP sending SETs >> to an IdP. >> > >> > With these requirements in mind I propose the >> following: >> > - both "sub" and "iss" to be defined at the event >> level >> > - "iss" at event level and at top SET level can >> be different >> > - "iss" and "sub" at event level can be different >> across events in the same SET >> > - "sub" should NOT be present at the top SET >> level (this solves the disambiguation), please note >> "should" and not "must" >> > >> > This solution also allows different profiles that >> define event types to define additional claims >> related to sub (like email or phone_number) and >> since all these claims will be at the event level >> there will be no collisions or ambiguity. >> > >> > Another proposal (which I supported) was to >> define a composite "aud" claim. This is not solving >> the requirement for a distinct SET issuer. Also, >> having the same claim name having different syntax >> in different token types could lead to confusion. >> > >> > And yet another proposal was to introduce a new >> claim for JWTs that defines a "type". This is not >> practical in the short term, and it also is not >> solving the distinct issuer requirement, but I think >> this is something the JWT group should seriously >> consider. >> > >> > Thoughts? >> > >> > Marius >> >> > _______________________________________________ >> > Id-event mailing list >> > Id-event@ietf.org >> > >> https://urldefense.proofpoint. >> com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Dev >> ent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10& >> r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp >> 74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88 >> YKOCd0mxPQFJLhxWI&e=3D >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> -- >> Adam Dawes | Sr. Product Manager |adawes@google.com >> |+1 650-214-2410 >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> -- >> Subscribe to the HARDTWARE mail list to >> learn about projects I am working on! >> >> >> >> -- >> >> Subscribe to the HARDTWARE mail list to learn >> about projects I am working on! >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --001a113ee31e4324a80551db48f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

"aud" (audience) specifies the target cli= ent, but not the intended usage (access token to authorize resource access = or SET to communicate a security event?)

"sco= pe" is not used by SET.

I don't know what= do you mean by "intend" (or intent)?

= =C2=A0


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs fro= m a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

 *From: *Id-event <id-event-bounces@ietf.org> on behalf of Di= ck Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
 *Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matak= e.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil= Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

 On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.co= m <mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gma= il.com
 =C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.inf= o/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" class=3D"cremed">adaw= es@google.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wro= te:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracl= e.com <mailto:phil.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= ailto:mscurtescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__w= ww.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRo= P1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0F= kITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzu= a6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event= @ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo= /id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org = <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |ad= awes@google.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>= |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <htt= p://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> m= ail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/lis= tinfo/id-event


_______________________________________________
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/lis= tinfo/id-event

--001a113ee31e4324a80551db48f0-- From nobody Tue Jun 13 17:33:43 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A761129426 for ; Tue, 13 Jun 2017 17:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.601 X-Spam-Level: X-Spam-Status: No, score=-14.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bfvaUotEo0B for ; Tue, 13 Jun 2017 17:33:38 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9699C129421 for ; Tue, 13 Jun 2017 17:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1497400417; x=1528936417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WdCOp1belLRmpWmJnF/35iDYHkLtiVlHuUo06uES7s8=; b=t4zfgqmZ4jisKNU+lODfVk5Dkk+gxLfxggizXdX/NkIhXG7/XmH4i/46 PfgwnICM2A+VGW51an9+7NzfKhhW6HWoQaD37uMVFTntjk1kJmEQplgMc DxwQWQ1/vkGe1eLhAdqSn4SDzLZsTDo93OZqrCbdzTwP1hndFvOL+bp6l U=; X-IronPort-AV: E=Sophos;i="5.39,339,1493683200"; d="scan'208,217";a="292925219" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-60013.pdx1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jun 2017 00:33:28 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-60013.pdx1.amazon.com (8.14.7/8.14.7) with ESMTP id v5E0XRN6002180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Jun 2017 00:33:28 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Jun 2017 00:33:27 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Jun 2017 00:33:27 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Wed, 14 Jun 2017 00:33:27 +0000 From: "Richard Backman, Annabelle" To: Marius Scurtescu , Henk Birkholz CC: ID Events Mailing List Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwAgAEftACAAJUjgP//9x6A Date: Wed, 14 Jun 2017 00:33:27 +0000 Message-ID: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.20] Content-Type: multipart/alternative; boundary="_000_0A8214E95FF748989D3CF518A9A31DC2amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:33:41 -0000 --_000_0A8214E95FF748989D3CF518A9A31DC2amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWNob2luZyBNYXJpdXPigJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVh biBieSDigJxpbnRlbmTigJ0/DQoNClRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBi ZXR0ZXIgYW5hbG9neSB3b3VsZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBt dWx0aS12YWx1ZWQgcHJvcGVydHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBv ZiB0aGUgSldULCBhbmQgdGhhdCBhIHJlY2lwaWVudCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1p bmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpXVCBiZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4gc29t ZSBjb250ZXh0Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2Vy dmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCkRhdGU6 IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPg0KQ2M6IElEIEV2ZW50cyBNYWlsaW5nIExp c3QgPGlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24g Zm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0K T24gVHVlLCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZT4+IHdyb3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFudGljcyB3b3Vs ZCAidXNhZ2UiIHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEgImludGVuZCIs ICJhdWRpZW5jZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNwZWNpZmllcyB0 aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tl biB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNl Y3VyaXR5IGV2ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoNCkkgZG9uJ3Qg a25vdyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0KDQoNCg0KDQpI ZW5rDQoNCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl IHdyb3RlOg0KVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsgdGhl IGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dlIGNhbuKAmXQg Z3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhj bHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQg ZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFp beKAnSBhcHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBj YW7igJl0IGJlIG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3SXQg aXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKA nGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0 aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3Jl IHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4g ZGlmZmVyZW50IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNs YWltcy4NCg0KKzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFkZXIg cGFyYW1ldGVyLg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCklkZW50aXR5 IFNlcnZpY2VzDQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCipE YXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1hcml1cyBTY3Vy dGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29t Pj4NCipDYzogKkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29v Z2xlLmNvbT4+LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtl LmpwPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVu dF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNF VCBpc3N1ZXINCg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNj dXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4gMTIsIDIwMTcg YXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0 bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1h aWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRo ZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUgaXMg ZGVzY3JpYmVkIGJ5ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBtaXRp Z2F0aW9uIGlzIGluICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxl cyBmb3INCiAgICBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNlIGRp ZmZlcmVudCBzZXRzIG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJlbnQg a2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZlcmVu dCBpc3N1ZXJzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGlsbCB0 aGluayB0aGF0IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5k DQogICAgc2FmZXR5Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIwMTcg YXQgOTo1OSBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtlIGFu ZCBJIGp1c3QgcHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9zZWxm LWlzc3VlZC5pbmZvLz9wPTE2OTANCg0KICAgICAgICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6 MDIgUE0gQWRhbSBEYXdlcyA8YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUu Y29tPg0KICAgICAgICA8bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29v Z2xlLmNvbT4+PiB3cm90ZToNCg0KICAgICAgICAgICAgSSB3YXMgaW5pdGlhbGx5IGEgZmFuIG9m IGtlZXBpbmcgU0VUUyB0byBiZSB2ZXJ5IHNpbWlsYXIgdG8NCiAgICAgICAgICAgIGlkIHRva2Vu cyBidXQgSSBub3cgdGhpbmsgdGhpcyBpcyBhIGJldHRlciBwbGFuLg0KDQogICAgICAgICAgICBP biBUaHUsIEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgPG5vdkBtYXRha2UuanA8 bWFpbHRvOm5vdkBtYXRha2UuanA+DQogICAgICAgICAgICA8bWFpbHRvOm5vdkBtYXRha2UuanA8 bWFpbHRvOm5vdkBtYXRha2UuanA+Pj4gd3JvdGU6DQoNCiAgICAgICAgICAgICAgICArMSBlc3Bl Y2lhbGx5IGZvciAidHlwZSINCg0KICAgICAgICAgICAgICAgIDIwMTctMDYtMDkgMTA6MzIgR01U KzA5OjAwIFBoaWwgSHVudCAoSURNKQ0KICAgICAgICAgICAgICAgIDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+IDxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4+Og0KDQogICAgICAgICAgICAgICAg ICAgICsxDQoNCiAgICAgICAgICAgICAgICAgICAgUGhpbA0KDQoNCiAgICAgICAgICAgICAgICAg ICAgID4gT24gSnVuIDgsIDIwMTcsIGF0IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3UNCiAgICAg ICAgICAgICAgICAgICAgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tPg0KICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xl LmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4+IHdyb3RlOg0KICAgICAgICAgICAg ICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBUaGVyZSB3ZXJlIGEgY291cGxlIG9m IHByb3Bvc2FscyBvbiBob3cgdG8NCiAgICAgICAgICAgICAgICAgICAgZGlzdGluZ3Vpc2ggU0VU cyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBpbg0KICAgICAgICAgICAgICAgICAg ICBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90DQogICAgICAg ICAgICAgICAgICAgIGNvbmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJp dHkNCiAgICAgICAgICAgICAgICAgICAgdnVsbmVyYWJpbGl0aWVzLg0KICAgICAgICAgICAgICAg ICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBUaGVyZSBpcyBhbHNvIGFub3RoZXIgaW1w b3J0YW50IHJlcXVpcmVtZW50OiB0aGUNCiAgICAgICAgICAgICAgICAgICAgU0VUIGlzc3VlciBp biBzb21lIGNhc2VzIG11c3QgYmUgZGlmZmVyZW50IGZyb20gdGhlDQogICAgICAgICAgICAgICAg ICAgICJzdWIiIGlzc3Vlci4gVGhpcyBpcyB0aGUgY2FzZSBvZiBhbiBSUCBzZW5kaW5nIFNFVHMN CiAgICAgICAgICAgICAgICAgICAgdG8gYW4gSWRQLg0KICAgICAgICAgICAgICAgICAgICAgPg0K ICAgICAgICAgICAgICAgICAgICAgPiBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkg cHJvcG9zZSB0aGUNCiAgICAgICAgICAgICAgICAgICAgZm9sbG93aW5nOg0KICAgICAgICAgICAg ICAgICAgICAgPiAtIGJvdGggInN1YiIgYW5kICJpc3MiIHRvIGJlIGRlZmluZWQgYXQgdGhlIGV2 ZW50DQogICAgICAgICAgICAgICAgICAgIGxldmVsDQogICAgICAgICAgICAgICAgICAgICA+IC0g ImlzcyIgYXQgZXZlbnQgbGV2ZWwgYW5kIGF0IHRvcCBTRVQgbGV2ZWwgY2FuDQogICAgICAgICAg ICAgICAgICAgIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGFu ZCAic3ViIiBhdCBldmVudCBsZXZlbCBjYW4gYmUgZGlmZmVyZW50DQogICAgICAgICAgICAgICAg ICAgIGFjcm9zcyBldmVudHMgaW4gdGhlIHNhbWUgU0VUDQogICAgICAgICAgICAgICAgICAgICA+ IC0gInN1YiIgc2hvdWxkIE5PVCBiZSBwcmVzZW50IGF0IHRoZSB0b3AgU0VUDQogICAgICAgICAg ICAgICAgICAgIGxldmVsICh0aGlzIHNvbHZlcyB0aGUgZGlzYW1iaWd1YXRpb24pLCBwbGVhc2Ug bm90ZQ0KICAgICAgICAgICAgICAgICAgICAic2hvdWxkIiBhbmQgbm90ICJtdXN0Ig0KICAgICAg ICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBUaGlzIHNvbHV0aW9uIGFs c28gYWxsb3dzIGRpZmZlcmVudCBwcm9maWxlcyB0aGF0DQogICAgICAgICAgICAgICAgICAgIGRl ZmluZSBldmVudCB0eXBlcyB0byBkZWZpbmUgYWRkaXRpb25hbCBjbGFpbXMNCiAgICAgICAgICAg ICAgICAgICAgcmVsYXRlZCB0byBzdWIgKGxpa2UgZW1haWwgb3IgcGhvbmVfbnVtYmVyKSBhbmQN CiAgICAgICAgICAgICAgICAgICAgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3aWxsIGJlIGF0IHRo ZSBldmVudCBsZXZlbA0KICAgICAgICAgICAgICAgICAgICB0aGVyZSB3aWxsIGJlIG5vIGNvbGxp c2lvbnMgb3IgYW1iaWd1aXR5Lg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAg ICAgICAgICAgPiBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvDQog ICAgICAgICAgICAgICAgICAgIGRlZmluZSBhIGNvbXBvc2l0ZSAiYXVkIiBjbGFpbS4gVGhpcyBp cyBub3Qgc29sdmluZw0KICAgICAgICAgICAgICAgICAgICB0aGUgcmVxdWlyZW1lbnQgZm9yIGEg ZGlzdGluY3QgIFNFVCBpc3N1ZXIuIEFsc28sDQogICAgICAgICAgICAgICAgICAgIGhhdmluZyB0 aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4DQogICAgICAgICAgICAg ICAgICAgIGluIGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi4N CiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5kIHlldCBh bm90aGVyIHByb3Bvc2FsIHdhcyB0byBpbnRyb2R1Y2UgYSBuZXcNCiAgICAgICAgICAgICAgICAg ICAgY2xhaW0gZm9yIEpXVHMgdGhhdCBkZWZpbmVzIGEgInR5cGUiLiBUaGlzIGlzIG5vdA0KICAg ICAgICAgICAgICAgICAgICBwcmFjdGljYWwgaW4gdGhlIHNob3J0IHRlcm0sIGFuZCBpdCBhbHNv IGlzIG5vdA0KICAgICAgICAgICAgICAgICAgICBzb2x2aW5nIHRoZSBkaXN0aW5jdCBpc3N1ZXIg cmVxdWlyZW1lbnQsIGJ1dCBJIHRoaW5rDQogICAgICAgICAgICAgICAgICAgIHRoaXMgaXMgc29t ZXRoaW5nIHRoZSBKV1QgZ3JvdXAgc2hvdWxkIHNlcmlvdXNseQ0KICAgICAgICAgICAgICAgICAg ICBjb25zaWRlci4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAg ID4gVGhvdWdodHM/DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAg ICA+IE1hcml1cw0KDQogICAgICAgICAgICAgICAgICAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgICAgICA+IElkLWV2 ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAg ICAgICAgICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0Fn JmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1KbXV1dEJ4NERBUHA3NEFVTGN4 MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJnM9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09D ZDBteFBRRkpMaHhXSSZlPQ0KDQogICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgICAgIElkLWV2 ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQogICAgICAgICAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAg ICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCiAgICAgICAgICAgIC0tDQogICAgICAg ICAgICBBZGFtIERhd2VzIHwgU3IuIFByb2R1Y3QgTWFuYWdlciB8YWRhd2VzQGdvb2dsZS5jb208 bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPg0KICAgICAgICAgICAgPG1haWx0bzphZGF3ZXNAZ29v Z2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+PiB8KzEgNjUwLTIxNC0yNDEwPHRlbDol MkIxJTIwNjUwLTIxNC0yNDEwPg0KICAgICAgICAgICAgPHRlbDooNjUwKSUyMDIxNC0yNDEwPg0K DQogICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICBJZC1l dmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KICAgICAgICAtLQ0KICAg ICAgICBTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSA8aHR0cDovL2hhcmR0d2FyZS5jb20vPiBt YWlsIGxpc3QgdG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9u IQ0KDQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdh cmUuY29tLz4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBv biENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZl bnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklk LWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0K DQo= --_000_0A8214E95FF748989D3CF518A9A31DC2amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <254A6ED165C5E14B9182DF5C7D219922@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K CWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MzMxNjQzNTYzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMjEyNjg5NDE5MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1NTkyODU5MzU7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzMjg3MTk0NDIg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RWNo b2luZyBNYXJpdXPigJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBi eSDigJxpbnRlbmTigJ0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VG8geW91ciBmaXJzdCBx dWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBLZXkg VXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVzIHRo ZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1heQ0K IHJlZmVyIHRvIHdoZW4gZGV0ZXJtaW5pbmcgd2hldGhlciB0byBhY2NlcHQgYSBKV1QgYmVpbmcg cHJlc2VudGVkIHRvIGl0IGluIHNvbWUgY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2Nv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPklkLWV2ZW50ICZsdDtpZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKdW5lIDEzLCAyMDE3IGF0IDExOjA1 IEFNPGJyPg0KPGI+VG86IDwvYj5IZW5rIEJpcmtob2x6ICZsdDtoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlJmd0Ozxicj4NCjxiPkNjOiA8L2I+SUQgRXZlbnRzIE1haWxpbmcgTGlzdCAm bHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDI6MTEg QU0sIEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZCBhIDJuZCBxdWVzdGlvbi48YnI+DQo8YnI+DQpXaGF0IHNlbWFudGlj cyB3b3VsZCAmcXVvdDt1c2FnZSZxdW90OyBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVy ZWQgdmlhICZxdW90O2ludGVuZCZxdW90OywgJnF1b3Q7YXVkaWVuY2UmcXVvdDssIGFuZCAmcXVv dDtzY29wZSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O2F1ZCZxdW90OyAoYXVkaWVuY2UpIHNwZWNpZmllcyB0 aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tl biB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNl Y3VyaXR5IGV2ZW50Pyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JnF1b3Q7c2NvcGUmcXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IGtu b3cgd2hhdCBkbyB5b3UgbWVhbiBieSAmcXVvdDtpbnRlbmQmcXVvdDsgKG9yIGludGVudCk/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KSGVuazxicj4NCjxicj4NCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVy ITxicj4NCjxicj4NCkkgdGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUg Zmxhd2VkOjxicj4NCjxicj4NCsK3V2UgY2Fu4oCZdCBndWFyYW50ZWUgdGhhdCBldmVyeSB0eXBl IG9mIEpXVCB3aWxsIGhhdmUgYSBtdXR1YWxseSBleGNsdXNpdmUgc2V0IG9mIHZhbGlkIGNsYWlt cyBhbmQvb3IgaGVhZGVyIHBhcmFtZXRlcnMsIGFuZCBlbmZvcmNpbmcgdGhpcyByZXF1aXJlcyBh IOKAnGZhaWwgb24gYW4gdW5yZWNvZ25pemVkIGNsYWlt4oCdIGFwcHJvYWNoIHRvIGVuc3VyZSB0 aGF0IEpXVHMgZnJvbSBzb21lIGZ1dHVyZSBzcGVjIGNhbuKAmXQgYmUgbWlzdGFrZW4gZm9yIEpX VHMNCiBmcm9tIGEgY3VycmVudCBzcGVjLjxicj4NCjxicj4NCsK3SXQgaXMgdW5yZWFsaXN0aWMg dG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVudCBrZXlz IGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5 IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVjYXVzZSBt YW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50IGtleXMu PGJyPg0KPGJyPg0KwrdEaXR0byBmb3Ig4oCcYXVk4oCdIGFuZCDigJxpc3PigJ0gY2xhaW1zLjxi cj4NCjxicj4NCiYjNDM7MSBmb3IgYSDigJx0eXBl4oCdIG9yIOKAnHVzYWdl4oCdIGNsYWltL2hl YWRlciBwYXJhbWV0ZXIuPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KQW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbjxicj4NCjxicj4NCklkZW50aXR5IFNlcnZpY2VzPGJyPg0KPGJyPg0KKkZyb206 ICpJZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQoqRGF0 ZTogKk1vbmRheSwgSnVuZSAxMiwgMjAxNyBhdCAzOjE4IFBNPGJyPg0KKlRvOiAqTWFyaXVzIFNj dXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KKkNjOiAqQWRhbSBE YXdlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+YWRhd2VzQGdvb2dsZS5jb208L2E+Jmd0OywgJnF1b3Q7bWF0YWtlLCBub3YmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFr ZS5qcDwvYT4mZ3Q7LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86 aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4m Z3Q7LA0KICZxdW90O1BoaWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208 L2E+Jmd0Ozxicj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8YnI+DQo8YnI+DQpB Z3JlZWQuIE5vdGUgdGhhdCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hh dCBzaG91bGQgYmUgaW4gMy45Ljxicj4NCjxicj4NCk9uIE1vbiwgSnVuIDEyLCAyMDE3IGF0IDM6 MTUgUE0sIE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IFRoYW5rcyBmb3IgdGhlIHBvaW50ZXIgRGljaywgdmVyeSBnb29kIHRpbWlu ZyA6LSk8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBpc3N1ZSBpcyBkZXNjcmliZWQgYnkg JnF1b3Q7Mi43LiBDcm9zcy1KV1QgQ29uZnVzaW9uJnF1b3Q7IGFuZCB0aGU8YnI+DQombmJzcDsg Jm5ic3A7IG1pdGlnYXRpb24gaXMgaW4gJnF1b3Q7My45LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZl IFZhbGlkYXRpb24gUnVsZXMgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyBEaWZmZXJlbnQgS2luZHMg b2YgSldUcyZxdW90Oywgc3BlY2lmaWNhbGx5ICZxdW90O1VzZSBkaWZmZXJlbnQgc2V0cyBvZjxi cj4NCiZuYnNwOyAmbmJzcDsgcmVxdWlyZWQgY2xhaW1zLi4uJnF1b3Q7LCAmcXVvdDtVc2UgZGlm ZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgSldU cy4mcXVvdDsgYW5kICZxdW90O1VzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtp bmRzIG9mIEpXVHMuJnF1b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBzdGlsbCB0aGlu ayB0aGF0IGEgJnF1b3Q7dHlwZSZxdW90OyBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFy aXR5IGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgc2FmZXR5Ljxicj4NCjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgTWFyaXVzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAy MDE3IGF0IDk6NTkgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPjxicj4N CiZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFyb24sIE1pa2Ug YW5kIEkganVzdCBwdWJsaXNoZWQgYW4gQkNQIElEIGZvciBKV1Q8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTY5MCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE2OTA8L2E+PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQg OTowMiBQTSBBZGFtIERhd2VzICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHdh cyBpbml0aWFsbHkgYSBmYW4gb2Yga2VlcGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkIHRva2VucyBi dXQgSSBub3cgdGhpbmsgdGhpcyBpcyBhIGJldHRlciBwbGFuLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQg Njo1NiBQTSBtYXRha2UsIG5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRh cmdldD0iX2JsYW5rIj5ub3ZAbWF0YWtlLmpwPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRh a2UuanAiIHRhcmdldD0iX2JsYW5rIj5ub3ZAbWF0YWtlLmpwPC9hPiZndDsmZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJiM0MzsxIGVzcGVjaWFsbHkgZm9yICZxdW90O3R5cGUmcXVvdDs8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDIwMTctMDYtMDkgMTA6MzIgR01UJiM0MzswOTowMCBQaGlsIEh1bnQgKElETSk8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7 Jmd0Ozo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFBoaWw8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBPbiBKdW4g OCwgMjAxNywgYXQgNjoyOCBQTSwgTWFyaXVzIFNjdXJ0ZXNjdTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29v Z2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcHJvcG9z YWxzIG9uIGhvdyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkaXN0aW5ndWlzaCBTRVRzIGZyb20gSWQg VG9rZW5zIGFuZCBBY2Nlc3MgVG9rZW5zIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1Y2ggYSB3YXkg dGhhdCBuYWl2ZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3Q8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29u ZnVzZSBvbmUgZm9yIHRoZSBvdGhlciBhbmQgb3BlbiB1cCBzZWN1cml0eTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB2dWxuZXJhYmlsaXRpZXMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSBpcyBhbHNvIGFub3RoZXIgaW1wb3J0YW50IHJl cXVpcmVtZW50OiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0VUIGlzc3VlciBpbiBzb21lIGNhc2Vz IG11c3QgYmUgZGlmZmVyZW50IGZyb20gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N1YiZx dW90OyBpc3N1ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHRvIGFuIElkUC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFdpdGggdGhlc2UgcmVxdWlyZW1lbnRzIGluIG1pbmQg SSBwcm9wb3NlIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb2xsb3dpbmc6PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsgLSBib3RoICZxdW90O3N1YiZxdW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7 IHRvIGJlIGRlZmluZWQgYXQgdGhlIGV2ZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxldmVsPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSAmcXVvdDtpc3MmcXVvdDsgYXQgZXZlbnQgbGV2ZWwg YW5kIGF0IHRvcCBTRVQgbGV2ZWwgY2FuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlIGRpZmZlcmVudDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDtz dWImcXVvdDsgYXQgZXZlbnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBhY3Jvc3MgZXZlbnRzIGluIHRoZSBzYW1lIFNFVDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IC0gJnF1b3Q7c3ViJnF1b3Q7IHNob3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNF VDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBsZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9u KSwgcGxlYXNlIG5vdGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c2hvdWxkJnF1b3Q7IGFuZCBu b3QgJnF1b3Q7bXVzdCZxdW90Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsgVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQg cHJvZmlsZXMgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVm aW5lIGFkZGl0aW9uYWwgY2xhaW1zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlbGF0ZWQgdG8gc3ViIChs aWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNpbmNlIGFs bCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWw8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS48YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFub3RoZXIgcHJv cG9zYWwgKHdoaWNoIEkgc3VwcG9ydGVkKSB3YXMgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5l IGEgY29tcG9zaXRlICZxdW90O2F1ZCZxdW90OyBjbGFpbS4gVGhpcyBpcyBub3Qgc29sdmluZzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB0aGUgcmVxdWlyZW1lbnQgZm9yIGEgZGlzdGluY3QmbmJzcDsgU0VU IGlzc3Vlci4gQWxzbyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaGF2aW5nIHRoZSBzYW1lIGNsYWltIG5h bWUgaGF2aW5nIGRpZmZlcmVudCBzeW50YXg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gZGlmZmVyZW50 IHRva2VuIHR5cGVzIGNvdWxkIGxlYWQgdG8gY29uZnVzaW9uLjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgQW5kIHlldCBhbm90aGVyIHBy b3Bvc2FsIHdhcyB0byBpbnRyb2R1Y2UgYSBuZXc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2xhaW0gZm9y IEpXVHMgdGhhdCBkZWZpbmVzIGEgJnF1b3Q7dHlwZSZxdW90Oy4gVGhpcyBpcyBub3Q8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBu b3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVt ZW50LCBidXQgSSB0aGluazxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlzIGlzIHNvbWV0aGluZyB0aGUg SldUIGdyb3VwIHNob3VsZCBzZXJpb3VzbHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uc2lkZXIuPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBU aG91Z2h0cz88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7IE1hcml1czxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyA8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2 ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4 UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJ Q0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1w O3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1 dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJ ajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmYW1wO2U9PC9hPjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQt ZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwv YT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAt LSA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBZGFtIERh d2VzIHwgU3IuIFByb2R1Y3QgTWFuYWdlciB8PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwv YT4mZ3Q7IHw8YSBocmVmPSJ0ZWw6JTJCMSUyMDY1MC0yMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsi PiYjNDM7MSA2NTAtMjE0LTI0MTA8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0O3RlbDooNjUwKSUyMDIxNC0yNDEwJmd0Ozxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQt ZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJzY3JpYmUgdG8g dGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL2hhcmR0d2FyZS5jb20vPC9hPiZndDsgbWFpbCBsaXN0IHRvPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29y a2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQpTdWJzY3JpYmUg dG8gdGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL2hhcmR0d2FyZS5jb20vPC9hPiZndDsgbWFpbCBsaXN0IHRvIGxl YXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklk LWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1l dmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0A8214E95FF748989D3CF518A9A31DC2amazoncom_-- From nobody Wed Jun 14 13:16:49 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DD129409 for ; Wed, 14 Jun 2017 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6LBX7z0BWnF for ; Wed, 14 Jun 2017 13:16:44 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0100.outbound.protection.outlook.com [104.47.37.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E03129548 for ; Wed, 14 Jun 2017 13:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IRkNZKJQ0ecKPG6lABDijC3yJBhSZ92geAdfiMiJ6cM=; b=anFLWjz0426qRGiEjnBpiuVYZGC4QgvY4/z6RSz8LhmkbPtEoeGXRcf69t68hnwW9aBg1gE0gYu+gO+I9bgushi/XHvTnlcLSvyQNWPd6je2XqlZrtxnGYM3u5NOiroZTP1xp0QcCONmUi3nzAc0Rk5o/FRAd1pN38U00USN8zc= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Wed, 14 Jun 2017 20:16:42 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1199.000; Wed, 14 Jun 2017 20:16:42 +0000 From: Mike Jones To: Marius Scurtescu CC: ID Events Mailing List , "Richard Backman, Annabelle" , Henk Birkholz Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nA= Date: Wed, 14 Jun 2017 20:16:42 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> In-Reply-To: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-14T13:16:30.5901470-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 7:cIShnLdNgE5o9QRr3NM2uErA2LlL1ezG3/ILtMCxKUGFQX+HSaMVRt2CaTm8tfRlcSpPvXGQFZKaztRZpLWLsv7A7Wllhry3+z/OxVy/ePdM6/RrM4WC/g2Is5+yKZmSFOOq/blzm/kanXRRG5mYrZMDuoxrs8rSty0BQOxXeWrAtFot9B9EWhJPTOurwnDCC9xXRvZKtPC7VTl1abOeuVwaoCI8XugdBdAP/D91p4s0iV0vOSIKaEr61bB7jdml7vRI8+hpsCb7jsNU6VKLO2C6PFtVxeYmp3nSRShN8/tynAFT+EOAL3uJEYhaYl2IFOQsg00uec3cD7JZhwJOBpQWjmKomCMM3nwf5FJ7Sc+9Uu5EwvOYh0LjViPfuFxfD4C2xhafPd08eidPEh9shwtW+EjU3ahUFPTZ/o5Oq8ndFFg7CZJYKD3GhQKDIbCrMxCofCG8e8yZA6W42gmoDicPQYQkeRctK6NQwesb9PPgdfQZN1I5xOlhQPR2CEUoLR0ZSUsldKuArKarheO8KlHfNkH/PB1MTrfF0MZP+A4SDurNmuyK0PBEB7IrIt2c9p0bZJhxq9C4hAV1b+6+k2jjzuGEmk4ZJEjnK6cCWGMxt9JyMksVEZUihig951zCdG9kwWmRj6lOyPPsqbbnHiZ1mgkoFzdMMjUfNYNmUofQ2sgAVYy2isi0130532/MburCeUTLNtZOJ2RO2Gwlo7Srw2RzhGApOyILTtpklBiv+uXoESumQN2uyytUSkZPn0/hWiSrGa4nLY6f7xtv7BGeHALiAVBAHS4hynnv0quh8I7tqvNOcrbxa4reYLY2 x-ms-office365-filtering-correlation-id: 7ed5a3f6-375c-47f6-7faa-08d4b36245dc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0630; x-ms-traffictypediagnostic: CY4PR21MB0630: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(211936372134217)(21748063052155)(5213294742642)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0630; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(39400400002)(209900001)(24454002)(377424004)(377454003)(51914003)(478600001)(5660300001)(7696004)(6436002)(74316002)(86612001)(86362001)(575784001)(8990500004)(81166006)(5005710100001)(77096006)(8936002)(2950100002)(10090500001)(6916009)(6506006)(122556002)(8676002)(229853002)(93886004)(2906002)(54356999)(76176999)(7906003)(606005)(561944003)(50986999)(33656002)(189998001)(7736002)(2900100001)(790700001)(6246003)(14454004)(53936002)(6116002)(102836003)(72206003)(966005)(3280700002)(3660700001)(10290500003)(53376002)(4326008)(110136004)(99286003)(6306002)(54896002)(55016002)(38730400002)(25786009)(53546009)(9686003)(236005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504FCB283E5305B0316C279F5C30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2017 20:16:42.4476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 20:16:48 -0000 --_000_CY4PR21MB0504FCB283E5305B0316C279F5C30CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW914oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4gIEnigJlkIGNo YXJhY3Rlcml6ZSB0aGUgcHJvcG9zYWxzIGluIHRoaXMgdGhyZWFkIGFzIOKAnHByZW1hdHVyZSBw ZXNzaW1hdGlvbuKAnSDigJMgbWFraW5nIHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hvdWxkIGJlIHNp bXBsZSBjb21wbGV4LCB3aXRob3V0IGRhdGEgc2hvd2luZyB0aGVyZeKAmXMgYW55IG5lZWQgdG8g ZG8gc28uDQoNCk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGluIHRoaXMg dGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0 dWFsbHkgZXZlbiBoYXZlLiAgSXTigJlzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hlZCB0aGF0IGl0 4oCZcyBpbXBvc3NpYmxlIGZvciBhIFNFVCB0byBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4g 4oCTIHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1 cnJlbnQvbXNnMDA0MjguaHRtbC4gIElmIHBlb3BsZSBoYXZlIGRhdGEgc2hvd2luZyB0aGF0IHRo aXMgaXMgcG9zc2libGUgd2l0aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9rZW5zIG9yIG90 aGVyIHJlYWwgSldUIGRlcGxveW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZpY3MsIHNvIHRo YXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEgdG8gaW5mb3JtIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5n IGNob2ljZXMgb24gb3VyIHBhcnQuDQoNClRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPigJ0sIHN1 Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1hbCB3YXks IG9yIHJlcXVpcmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNseSBzaW1wbGUg dGhpbmdzIHVubmVjZXNzYXJpbHkgY29tcGxleC4gIFllcywgdGhlbiB0aGUgcmVzdWx0IGlzIHRo ZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1dCBhIGNvbnNlcXVlbmNlIG9mIHRoaXMg aXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxkIGhhdmUgdG8gYmUgdXNlZCwgcmF0aGVy IHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiAgVGhlIG1vcmUgdW53aWVsZHkgd2UgbWFrZSBp dCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVsb3BlcnMgYXJlIHRvIGp1c3QgY3Jl YXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuICBLZWVwaW5nIGl0IHNpbXBsZSBpcyB0aGUg a2V5IHRvIGFkb3B0aW9uLiAgU3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0aGV5IGFyZSBh Y3R1YWxseSB1c2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlDQpTZW50 OiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxt c2N1cnRlc2N1QGdvb2dsZS5jb20+OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlPg0KQ2M6IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tl biBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KRWNob2luZyBNYXJpdXPigJlz IHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieSDigJxpbnRlbmTigJ0/ DQoNClRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3b3Vs ZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJvcGVy dHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBhbmQgdGhh dCBhIHJlY2lwaWVudCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRvIGFj Y2VwdCBhIEpXVCBiZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4gc29tZSBjb250ZXh0Lg0KDQotLQ0K QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJ ZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdv b2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBK dW5lIDEzLCAyMDE3IGF0IDExOjA1IEFNDQpUbzogSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9s ekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZT4+DQpDYzogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OmlkLWV2ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZv ciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCk9u IFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hv bHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIu ZGU+PiB3cm90ZToNCkFuZCBhIDJuZCBxdWVzdGlvbi4NCg0KV2hhdCBzZW1hbnRpY3Mgd291bGQg InVzYWdlIiBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICJpbnRlbmQiLCAi YXVkaWVuY2UiLCBhbmQgInNjb3BlIj8NCg0KImF1ZCIgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhl IHRhcmdldCBjbGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4g dG8gYXV0aG9yaXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1 cml0eSBldmVudD8pDQoNCiJzY29wZSIgaXMgbm90IHVzZWQgYnkgU0VULg0KDQpJIGRvbid0IGtu b3cgd2hhdCBkbyB5b3UgbWVhbiBieSAiaW50ZW5kIiAob3IgaW50ZW50KT8NCg0KDQoNCg0KSGVu aw0KDQpPbiAwNi8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSB3 cm90ZToNClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyIQ0KDQpJIHRoaW5rIHRoZSBh c3N1bXB0aW9ucyBpbmhlcmVudCBpbiAzLjkgYXJlIGZsYXdlZDoNCg0KwrdXZSBjYW7igJl0IGd1 YXJhbnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4Y2x1 c2l2ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5kIGVu Zm9yY2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xhaW3i gJ0gYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMgY2Fu 4oCZdCBiZSBtaXN0YWtlbiBmb3IgSldUcyBmcm9tIGEgY3VycmVudCBzcGVjLg0KDQrCt0l0IGlz IHVucmVhbGlzdGljIHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRoZXJlIHRvIHRoZSDigJxk aWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPigJ0gcnVsZS4gV2hldGhl ciBtYW5kYXRlZCBieSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVycyB3aWxsIGlnbm9yZSB0 aGlzIGJlY2F1c2UgbWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhhbiBtYW5hZ2luZyBOIGRp ZmZlcmVudCBrZXlzLg0KDQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBjbGFp bXMuDQoNCisxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBh cmFtZXRlci4NCg0KLS0NCg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQpJZGVudGl0eSBT ZXJ2aWNlcw0KDQoqRnJvbTogKklkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQg PGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQoqRGF0 ZTogKk1vbmRheSwgSnVuZSAxMiwgMjAxNyBhdCAzOjE4IFBNDQoqVG86ICpNYXJpdXMgU2N1cnRl c2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+ DQoqQ2M6ICpBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb20+PiwgIm1hdGFrZSwgbm92IiA8bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5q cD4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+PiwgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZlbnRd IHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQg aXNzdWVyDQoNCkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMgb2YgZGlzY3Vz c2lvbiBvbiB3aGF0IHNob3VsZCBiZSBpbiAzLjkuDQoNCk9uIE1vbiwgSnVuIDEyLCAyMDE3IGF0 IDM6MTUgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86 bXNjdXJ0ZXNjdUBnb29nbGUuY29tPiA8bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4+IHdyb3RlOg0KDQogICAgVGhhbmtzIGZvciB0aGUg cG9pbnRlciBEaWNrLCB2ZXJ5IGdvb2QgdGltaW5nIDotKQ0KDQogICAgVGhlIGlzc3VlIGlzIGRl c2NyaWJlZCBieSAiMi43LiBDcm9zcy1KV1QgQ29uZnVzaW9uIiBhbmQgdGhlDQogICAgbWl0aWdh dGlvbiBpcyBpbiAiMy45LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZlIFZhbGlkYXRpb24gUnVsZXMg Zm9yDQogICAgRGlmZmVyZW50IEtpbmRzIG9mIEpXVHMiLCBzcGVjaWZpY2FsbHkgIlVzZSBkaWZm ZXJlbnQgc2V0cyBvZg0KICAgIHJlcXVpcmVkIGNsYWltcy4uLiIsICJVc2UgZGlmZmVyZW50IGtl eXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZg0KICAgIEpXVHMuIiBhbmQgIlVzZSBkaWZmZXJlbnQg aXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuIi4NCg0KICAgIEkgc3RpbGwgdGhp bmsgdGhhdCBhICJ0eXBlIiBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFuZA0K ICAgIHNhZmV0eS4NCg0KDQogICAgTWFyaXVzDQoNCiAgICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0 IDk6NTkgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbT4NCiAgICA8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT4+PiB3cm90ZToNCg0KICAgICAgICBZYXJvbiwgTWlrZSBhbmQg SSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVA0KICAgICAgICBodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby8/cD0xNjkwDQoNCiAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAy IFBNIEFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bT4NCiAgICAgICAgPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb20+Pj4gd3JvdGU6DQoNCiAgICAgICAgICAgIEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBr ZWVwaW5nIFNFVFMgdG8gYmUgdmVyeSBzaW1pbGFyIHRvDQogICAgICAgICAgICBpZCB0b2tlbnMg YnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi4NCg0KICAgICAgICAgICAgT24g VGh1LCBKdW4gOCwgMjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0YWtlLmpwPG1h aWx0bzpub3ZAbWF0YWtlLmpwPg0KICAgICAgICAgICAgPG1haWx0bzpub3ZAbWF0YWtlLmpwPG1h aWx0bzpub3ZAbWF0YWtlLmpwPj4+IHdyb3RlOg0KDQogICAgICAgICAgICAgICAgKzEgZXNwZWNp YWxseSBmb3IgInR5cGUiDQoNCiAgICAgICAgICAgICAgICAyMDE3LTA2LTA5IDEwOjMyIEdNVCsw OTowMCBQaGlsIEh1bnQgKElETSkNCiAgICAgICAgICAgICAgICA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+PjoNCg0KICAgICAgICAgICAgICAgICAg ICArMQ0KDQogICAgICAgICAgICAgICAgICAgIFBoaWwNCg0KDQogICAgICAgICAgICAgICAgICAg ICA+IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAg ICAgICAgICAgICAgIDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbT4NCiAgICAgICAgICAgICAgICAgICAgPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+PiB3cm90ZToNCiAgICAgICAgICAgICAg ICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBw cm9wb3NhbHMgb24gaG93IHRvDQogICAgICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMg ZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2VzcyBUb2tlbnMgaW4NCiAgICAgICAgICAgICAgICAgICAg c3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAg ICAgICAgICAgICBjb25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5 DQogICAgICAgICAgICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4NCiAgICAgICAgICAgICAgICAg ICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9y dGFudCByZXF1aXJlbWVudDogdGhlDQogICAgICAgICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4g c29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAg ICAic3ViIiBpc3N1ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQog ICAgICAgICAgICAgICAgICAgIHRvIGFuIElkUC4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAg ICAgICAgICAgICAgICAgICAgID4gV2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHBy b3Bvc2UgdGhlDQogICAgICAgICAgICAgICAgICAgIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAg ICAgICAgID4gLSBib3RoICJzdWIiIGFuZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVu dA0KICAgICAgICAgICAgICAgICAgICBsZXZlbA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJp c3MiIGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbg0KICAgICAgICAgICAg ICAgICAgICBiZSBkaWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQg InN1YiIgYXQgZXZlbnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAg ICBhY3Jvc3MgZXZlbnRzIGluIHRoZSBzYW1lIFNFVA0KICAgICAgICAgICAgICAgICAgICAgPiAt ICJzdWIiIHNob3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAg ICAgICAgICBsZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5v dGUNCiAgICAgICAgICAgICAgICAgICAgInNob3VsZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAg ICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNv IGFsbG93cyBkaWZmZXJlbnQgcHJvZmlsZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICBkZWZp bmUgZXZlbnQgdHlwZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAg ICAgICAgIHJlbGF0ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kDQog ICAgICAgICAgICAgICAgICAgIHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUg ZXZlbnQgbGV2ZWwNCiAgICAgICAgICAgICAgICAgICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNp b25zIG9yIGFtYmlndWl0eS4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAg ICAgICAgID4gQW5vdGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAg ICAgICAgICAgICAgICAgICBkZWZpbmUgYSBjb21wb3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMg bm90IHNvbHZpbmcNCiAgICAgICAgICAgICAgICAgICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRp c3RpbmN0ICBTRVQgaXNzdWVyLiBBbHNvLA0KICAgICAgICAgICAgICAgICAgICBoYXZpbmcgdGhl IHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRheA0KICAgICAgICAgICAgICAg ICAgICBpbiBkaWZmZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uDQog ICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5v dGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3DQogICAgICAgICAgICAgICAgICAg IGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAg ICAgICAgICAgICAgICAgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBp cyBub3QNCiAgICAgICAgICAgICAgICAgICAgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJl cXVpcmVtZW50LCBidXQgSSB0aGluaw0KICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0 aGluZyB0aGUgSldUIGdyb3VwIHNob3VsZCBzZXJpb3VzbHkNCiAgICAgICAgICAgICAgICAgICAg Y29uc2lkZXIuDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+ IFRob3VnaHRzPw0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAg PiBNYXJpdXMNCg0KICAgICAgICAgICAgICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAg ICAgICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1 Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09Sm11dXRCeDREQVBwNzRBVUxjeDJJ X2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2Qw bXhQUUZKTGh4V0kmZT0NCg0KICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KICAgICAgICAgICAgICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAg SWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQogICAgICAgICAgICAtLQ0KICAgICAgICAg ICAgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfGFkYXdlc0Bnb29nbGUuY29tPG1h aWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4gfCsxIDY1MC0yMTQtMjQxMDx0ZWw6JTJC MSUyMDY1MC0yMTQtMjQxMD4NCiAgICAgICAgICAgIDx0ZWw6KDY1MCklMjAyMTQtMjQxMD4NCg0K ICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgSWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGll dGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCiAgICAgICAgLS0NCiAgICAg ICAgU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLz4gbWFp bCBsaXN0IHRvDQogICAgICAgIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEN Cg0KDQoNCi0tDQoNClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFIDxodHRwOi8vaGFyZHR3YXJl LmNvbS8+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24h DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1l dmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0K --_000_CY4PR21MB0504FCB283E5305B0316C279F5C30CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+WW914oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXph dGlvbuKAnS4mbmJzcDsgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0 aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRo YXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhvdXQNCiBkYXRhIHNob3dp bmcgdGhlcmXigJlzIGFueSBuZWVkIHRvIGRvIHNvLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bv c2VkIGluIHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNl IHRoYXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZlLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSBiZWVuIGVz dGFibGlzaGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yDQogYSBTRVQgdG8gYmUgY29uZnVz ZWQgZm9yIGFuIElEIFRva2VuIOKAkyBzZWUgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4Lmh0bWwiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4 Lmh0bWw8L2E+LiZuYnNwOyBJZiBwZW9wbGUgaGF2ZSBkYXRhIHNob3dpbmcgdGhhdCB0aGlzIGlz IHBvc3NpYmxlIHdpdGggc3BlY2lmaWMga2luZHMgb2YgQWNjZXNzIFRva2VucyBvciBvdGhlciBy ZWFsIEpXVCBkZXBsb3ltZW50cywgcGxlYXNlIHByb3ZpZGUgc3BlY2lmaWNzLCBzbyB0aGF0IHdl IGNhbiB1c2UgdGhhdCBkYXRhIHRvIGluZm9ybQ0KIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNo b2ljZXMgb24gb3VyIHBhcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPigJ0s IHN1Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1hbCB3 YXksIG9yIHJlcXVpcmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNseSBzaW1w bGUgdGhpbmdzIHVubmVjZXNzYXJpbHkgY29tcGxleC4mbmJzcDsgWWVzLCB0aGVuDQogdGhlIHJl c3VsdCBpcyB0aGVuIGRpZmZlcmVudCB0aGFuIGEgbm9ybWFsIEpXVCBidXQgYSBjb25zZXF1ZW5j ZSBvZiB0aGlzIGlzIHRoYXQgY3VzdG9tIHBhcnNpbmcgY29kZSB3b3VsZCBoYXZlIHRvIGJlIHVz ZWQsIHJhdGhlciB0aGFuIGEgc3RhbmRhcmQgSldUIHBhcnNlci4mbmJzcDsgVGhlIG1vcmUgdW53 aWVsZHkgd2UgbWFrZSBpdCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVsb3BlcnMg YXJlIHRvIGp1c3QgY3JlYXRlIHRoZWlyIG93bg0KIGRhdGEgc3RydWN0dXJlcy4mbmJzcDsgS2Vl cGluZyBpdCBzaW1wbGUgaXMgdGhlIGtleSB0byBhZG9wdGlvbi4mbmJzcDsgU3RhbmRhcmRzIGFy ZSBvbmx5IHVzZWZ1bCBpZiB0aGV5IGFyZSBhY3R1YWxseSB1c2VkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSWQtZXZlbnQgW21haWx0 bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEzLCAy MDE3IDU6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcml1cyBTY3VydGVzY3UgJmx0O21zY3VydGVz Y3VAZ29vZ2xlLmNvbSZndDs7IEhlbmsgQmlya2hvbHogJmx0O2hlbmsuYmlya2hvbHpAc2l0LmZy YXVuaG9mZXIuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZs dDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVu dF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNF VCBpc3N1ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjogY2FuIHlvdSBleHBs YWluIHdoYXQgeW91IG1lYW4gYnkg4oCcaW50ZW5k4oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbyB5b3Vy IGZpcnN0IHF1ZXN0aW9uLCBJIHRoaW5rIGEgYmV0dGVyIGFuYWxvZ3kgd291bGQgYmUgdGhlIFgu NTA5IEtleSBVc2FnZSBleHRlbnNpb246IGEgbXVsdGktdmFsdWVkIHByb3BlcnR5IHRoYXQgZGVj bGFyZXMgdGhlIGludGVuZGVkIHB1cnBvc2Ugb2YgdGhlIEpXVCwgYW5kIHRoYXQgYSByZWNpcGll bnQNCiBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpX VCBiZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4gc29tZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZGVudGl0eSBTZXJ2aWNl czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1 cnRlc2N1QGdvb2dsZS5jb20iPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPlR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU08YnI+DQo8Yj5Ubzog PC9iPkhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+ DQo8Yj5DYzogPC9iPklEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1 c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1 biAxMywgMjAxNyBhdCAyOjExIEFNLCBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86 aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmly a2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QW5kIGEgMm5kIHF1ZXN0aW9uLjxicj4NCjxicj4NCldoYXQgc2VtYW50aWNz IHdvdWxkICZxdW90O3VzYWdlJnF1b3Q7IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJl ZCB2aWEgJnF1b3Q7aW50ZW5kJnF1b3Q7LCAmcXVvdDthdWRpZW5jZSZxdW90OywgYW5kICZxdW90 O3Njb3BlJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7YXVkJnF1b3Q7IChhdWRpZW5jZSkgc3BlY2lmaWVzIHRo ZSB0YXJnZXQgY2xpZW50LCBidXQgbm90IHRoZSBpbnRlbmRlZCB1c2FnZSAoYWNjZXNzIHRva2Vu IHRvIGF1dGhvcml6ZSByZXNvdXJjZSBhY2Nlc3Mgb3IgU0VUIHRvIGNvbW11bmljYXRlIGEgc2Vj dXJpdHkgZXZlbnQ/KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mcXVvdDtzY29wZSZxdW90OyBpcyBub3QgdXNlZCBieSBTRVQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3Qga25v dyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICZxdW90O2ludGVuZCZxdW90OyAob3IgaW50ZW50KT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KSGVuazxi cj4NCjxicj4NCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHB1dHRp bmcgdGhpcyB0b2dldGhlciE8YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSBhc3N1bXB0aW9ucyBpbmhl cmVudCBpbiAzLjkgYXJlIGZsYXdlZDo8YnI+DQo8YnI+DQrCt1dlIGNhbuKAmXQgZ3VhcmFudGVl IHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHNl dCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQgZW5mb3JjaW5n IHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFpbeKAnSBhcHBy b2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBjYW7igJl0IGJl IG1pc3Rha2VuIGZvciBKV1RzDQogZnJvbSBhIGN1cnJlbnQgc3BlYy48YnI+DQo8YnI+DQrCt0l0 IGlzIHVucmVhbGlzdGljIHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRoZXJlIHRvIHRoZSDi gJxkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPigJ0gcnVsZS4gV2hl dGhlciBtYW5kYXRlZCBieSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVycyB3aWxsIGlnbm9y ZSB0aGlzIGJlY2F1c2UgbWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhhbiBtYW5hZ2luZyBO IGRpZmZlcmVudCBrZXlzLjxicj4NCjxicj4NCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCc aXNz4oCdIGNsYWltcy48YnI+DQo8YnI+DQomIzQzOzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1 c2FnZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1ldGVyLjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4N CkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48YnI+DQo8YnI+DQpJZGVudGl0eSBTZXJ2aWNlczxi cj4NCjxicj4NCipGcm9tOiAqSWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KKkRhdGU6ICpNb25kYXksIEp1bmUgMTIsIDIwMTcgYXQgMzoxOCBQTTxicj4N CipUbzogKk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxi cj4NCipDYzogKkFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDssICZxdW90O21hdGFr ZSwgbm92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJf YmxhbmsiPm5vdkBtYXRha2UuanA8L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZl bnRAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDtQaGlsIEh1bnQgKElETSkmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZlbnRdIHNv bHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNz dWVyPGJyPg0KPGJyPg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBk aXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS48YnI+DQo8YnI+DQpPbiBNb24sIEp1 biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29n bGUuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHRoZSBwb2ludGVyIERpY2ss IHZlcnkgZ29vZCB0aW1pbmcgOi0pPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgaXNzdWUg aXMgZGVzY3JpYmVkIGJ5ICZxdW90OzIuNy4gQ3Jvc3MtSldUIENvbmZ1c2lvbiZxdW90OyBhbmQg dGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBtaXRpZ2F0aW9uIGlzIGluICZxdW90OzMuOS4gVXNlIE11 dHVhbGx5IEV4Y2x1c2l2ZSBWYWxpZGF0aW9uIFJ1bGVzIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsg RGlmZmVyZW50IEtpbmRzIG9mIEpXVHMmcXVvdDssIHNwZWNpZmljYWxseSAmcXVvdDtVc2UgZGlm ZmVyZW50IHNldHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IHJlcXVpcmVkIGNsYWltcy4uLiZxdW90 OywgJnF1b3Q7VXNlIGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2Y8YnI+DQom bmJzcDsgJm5ic3A7IEpXVHMuJnF1b3Q7IGFuZCAmcXVvdDtVc2UgZGlmZmVyZW50IGlzc3VlcnMg Zm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzLiZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IEkgc3RpbGwgdGhpbmsgdGhhdCBhICZxdW90O3R5cGUmcXVvdDsgY2xhaW0gd291bGQgYnJp bmcgYSBsb3Qgb2YgY2xhcml0eSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IHNhZmV0eS48YnI+DQo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE1hcml1czxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg T24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjU5IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdt YWlsLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5j b208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFlhcm9uLCBNaWtlIGFuZCBJIGp1c3QgcHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3Vl ZC5pbmZvLz9wPTE2OTAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/ cD0xNjkwPC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUs IEp1biA4LCAyMDE3IGF0IDk6MDIgUE0gQWRhbSBEYXdlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFk YXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+ Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgSSB3YXMgaW5pdGlhbGx5IGEgZmFuIG9mIGtlZXBpbmcgU0VUUyB0byBiZSB2 ZXJ5IHNpbWlsYXIgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBpZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUs IEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgJmx0OzxhIGhyZWY9Im1haWx0bzpu b3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwvYT48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwvYT4m Z3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7MSBlc3BlY2lhbGx5IGZvciAmcXVvdDt0eXBl JnF1b3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAyMDE3LTA2LTA5IDEwOjMyIEdNVCYjNDM7MDk6MDAgUGhpbCBIdW50 IChJRE0pPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+Jmd0OyZndDs6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7MTxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBQaGlsPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgT24gSnVuIDgsIDIwMTcsIGF0IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3U8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSB3ZXJlIGEg Y291cGxlIG9mIHByb3Bvc2FscyBvbiBob3cgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlzdGluZ3Vp c2ggU0VUcyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBpbjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGNvbmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJp dHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdnVsbmVyYWJpbGl0aWVzLjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUgaXMgYWxzbyBhbm90 aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNFVCBpc3N1 ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmcXVvdDtzdWImcXVvdDsgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNl bmRpbmcgU0VUczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBhbiBJZFAuPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBXaXRoIHRoZXNlIHJlcXVp cmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9sbG93aW5n Ojxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gYm90aCAmcXVvdDtzdWImcXVvdDsgYW5k ICZxdW90O2lzcyZxdW90OyB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7 IGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O2lzcyZx dW90OyBhbmQgJnF1b3Q7c3ViJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQ8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O3N1YiZxdW90OyBzaG91bGQgTk9UIGJlIHByZXNl bnQgYXQgdGhlIHRvcCBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2ZWwgKHRoaXMgc29sdmVzIHRo ZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFzZSBub3RlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3No b3VsZCZxdW90OyBhbmQgbm90ICZxdW90O211c3QmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoaXMgc29sdXRpb24gYWxzbyBh bGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGV2 ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBy ZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFuZDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxldmVs PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJlIHdpbGwgYmUgbm8gY29sbGlzaW9ucyBvciBhbWJpZ3Vp dHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGRlZmluZSBhIGNvbXBvc2l0ZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0uIFRoaXMg aXMgbm90IHNvbHZpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRp c3RpbmN0Jm5ic3A7IFNFVCBpc3N1ZXIuIEFsc28sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGhhdmluZyB0 aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGluIGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi48YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFu ZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBhICZxdW90O3R5cGUmcXVvdDsuIFRo aXMgaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwg YW5kIGl0IGFsc28gaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNvbHZpbmcgdGhlIGRpc3RpbmN0 IGlzc3VlciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhpcyBp cyBzb21ldGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGNvbnNpZGVyLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsgVGhvdWdodHM/PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpJZC1ldmVudEBpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpq V3dsTktlNENfbExJR2smYW1wO209Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhx V2dmeHFtZyZhbXA7cz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJ JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smYW1wO209Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZh bXA7cz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmFtcDtlPTwv YT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3Jn PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLS0gPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfDxhIGhyZWY9Im1haWx0 bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9h Pjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRh d2VzQGdvb2dsZS5jb208L2E+Jmd0OyB8PGEgaHJlZj0idGVsOiUyQjElMjA2NTAtMjE0LTI0MTAi IHRhcmdldD0iX2JsYW5rIj4mIzQzOzEgNjUwLTIxNC0yNDEwPC9hPjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJ0ZWw6KDY1MCklMjAy MTQtMjQxMCI+dGVsOig2NTApJTIwMjE0LTI0MTA8L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJzY3JpYmUgdG8gdGhlIEhB UkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL2hhcmR0d2FyZS5jb20vPC9hPiZndDsgbWFpbCBsaXN0IHRvPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBv biE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQpTdWJzY3JpYmUgdG8gdGhl IEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cDovL2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL2hhcmR0d2FyZS5jb20vPC9hPiZndDsgbWFpbCBsaXN0IHRvIGxlYXJuIGFi b3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0504FCB283E5305B0316C279F5C30CY4PR21MB0504namp_-- From nobody Wed Jun 14 17:25:41 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23171129420 for ; Wed, 14 Jun 2017 17:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyciqcEmAkhs for ; Wed, 14 Jun 2017 17:25:36 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B5C127241 for ; Wed, 14 Jun 2017 17:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1497486336; x=1529022336; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ct3X33mJamP53dDj20AzlROQzrz5OrvAmsa+UDFE7bY=; b=vNUPYSVFbiGR4tqcYbVfHGMAEj0kVpvLtbcHMJ/yNCDx0UT9Fml+nXcx aPxR3cXQWL9YyVsszDoHd3R1szMfRqAZjMADDJx0rver79kHSJ5Drbcua LqbVCUIr/TGQ+pqa4pdC+nLDrwAeOh9McImnbjXjtlQwaJ8kExg0dGEvT M=; X-IronPort-AV: E=Sophos;i="5.39,341,1493683200"; d="scan'208,217";a="653680182" Received: from iad6-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-62008.pdx2.amazon.com) ([10.124.125.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Jun 2017 00:25:28 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-62008.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP id v5F0PNE9029284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2017 00:25:26 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Jun 2017 00:25:26 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Jun 2017 00:25:25 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Thu, 15 Jun 2017 00:25:25 +0000 From: "Richard Backman, Annabelle" To: Mike Jones , Marius Scurtescu CC: ID Events Mailing List , Henk Birkholz Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwAgAEftACAAJUjgP//9x6AgAG/8QD//9AlgA== Date: Thu, 15 Jun 2017 00:25:25 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.20] Content-Type: multipart/alternative; boundary="_000_D3FA82F3E63E4C0B88C418477FDA730Aamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 00:25:40 -0000 --_000_D3FA82F3E63E4C0B88C418477FDA730Aamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCg0KWW91ciBleHBsYW5hdGlvbiBmb3Igd2h5IHRoaXMgaXMgYSBub24tcHJvYmxlbSBp cyBkZXBlbmRlbnQgdXBvbiBzaWRlIGVmZmVjdHMgb2YgZWxlbWVudHMgb2YgT3BlbklEIENvbm5l Y3QgdGhhdCB3ZXJlIG5vdCBkZXNpZ25lZCB0byBzb2x2ZSB0aGlzIGlzc3VlLiBBcyBhIHJlc3Vs dCwgSSBzZWUgc2V2ZXJhbCBpc3N1ZXMgd2l0aCBpdDoNCg0KMS4gICAgICAgVGhlIGNhbGxlciBv ZiB0aGUgVG9rZW4gRW5kcG9pbnQgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBjYW4gYmUgY2VydGFp biB0aGF0IGEgbm9uY2UtbGVzcyBJRCBUb2tlbiBpcyByZWFsbHkgYW4gSUQgVG9rZW4uIEFueSBw YXJ0eSB0aGF0IHRoZSBjYWxsZXIgcGFzc2VzIHRoZSBJRCBUb2tlbiBvZmYgdG8gaGFzIG5vIHdh eSB0byB2ZXJpZnkgaXRzIHByb3ZlbmFuY2UuDQoNCjIuICAgICAgIEFueSBmdXR1cmUgSUQgVG9r ZW4gZGlzdHJpYnV0aW9uIG1ldGhvZCBuZWVkcyB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYWdhaW4u DQoNCjMuICAgICAgTm8gb3RoZXIgcHJvZmlsZSBvZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAibm9u Y2XigJ0gY2xhaW0uDQoNCjQuICAgICAgVGhpcyBpcyBvbmx5IGEgc29sdXRpb24gZm9yIElEIFRv a2Vucy4gRXZlcnkgb3RoZXIgSldUIHByb2ZpbGUgdGhhdCBjYXJlcyBhYm91dCBkaXNhbWJpZ3Vh dGlvbiBoYXMgdG8gaW52ZW50IGl0cyBvd24gc29sdXRpb24gdG8gdGhlIHByb2JsZW0uDQoNCldl IGtub3cgZnJvbSBleHBlcmllbmNlIHRoYXQgbmFtaW5nIGNvbGxpc2lvbnMgYW5kIHJlcGxheSBh dHRhY2tzIGFyZSBib3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4gV2hhdOKAmXMgYmVpbmcgcHJvcG9z ZWQgaXMgYSBzaW1wbGUsIGRlZmVuc2l2ZSBtZWFzdXJlIGFnYWluc3QgdGhlc2Ugcmlza3MuIFlv dSBicm91Z2h0IHVwIEpXVCBsaWJyYXJpZXM6IGEgZ2VuZXJhbCBzb2x1dGlvbiBhY3R1YWxseSBt YWtlcyBpdCBlYXNpZXIgdG8gdXNlIGNvbW1vbiBsaWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBB IOKAnHVzYWdlLWF3YXJl4oCdIEpXVCBsaWJyYXJ5IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlv biBmb3IgYW55IEpXVCBwcm9maWxlLCB3aGVyZWFzIHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBw cm9maWxlIHdvdWxkIHJlcXVpcmUgdW5pcXVlIGxvZ2ljLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyBhdCAxOjE2 IFBNDQpUbzogTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KQ2M6ICJS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBJRCBFdmVu dHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz4sIEhlbmsgQmlya2hvbHogPGhlbmsu Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1 dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vl cg0KDQpZb3XigJl2ZSBoZWFyZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiAgSeKA mWQgY2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0 dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQg YmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhvdXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVl ZCB0byBkbyBzby4NCg0KTWFuZGF0b3J5IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4g dGhpcyB0aHJlYWQgdG8gcHJvYmxlbXMgdGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3 ZSBhY3R1YWxseSBldmVuIGhhdmUuICBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkIHRo YXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBU b2tlbiDigJMgc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZl bnQvY3VycmVudC9tc2cwMDQyOC5odG1sLiAgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93aW5nIHRo YXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBUb2tlbnMg b3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNpZmljcywg c28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0gYXBwcm9wcmlhdGUgZW5naW5l ZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC4NCg0KVGhlIHByb3Bvc2VkIOKAnHNvbHV0aW9uc+KA nSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0aGUgbm9ybWFs IHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2aW91c2x5IHNp bXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4LiAgWWVzLCB0aGVuIHRoZSByZXN1bHQg aXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ugb2Yg dGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1c2VkLCBy YXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuICBUaGUgbW9yZSB1bndpZWxkeSB3ZSBt YWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxvcGVycyBhcmUgdG8ganVz dCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4gIEtlZXBpbmcgaXQgc2ltcGxlIGlz IHRoZSBrZXkgdG8gYWRvcHRpb24uICBTdGFuZGFyZHMgYXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkg YXJlIGFjdHVhbGx5IHVzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUN ClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNTozMyBQTQ0KVG86IE1hcml1cyBTY3VydGVz Y3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbT47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGU+DQpDYzogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNz IFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hvaW5nIE1hcml1 c+KAmXMgcXVlc3Rpb246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVu ZOKAnT8NCg0KVG8geW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5 IHdvdWxkIGJlIHRoZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBw cm9wZXJ0eSB0aGF0IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFu ZCB0aGF0IGEgcmVjaXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIg dG8gYWNjZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuDQoN Ci0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZy b206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVz Y3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6IFR1ZXNk YXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxoZW5rLmJp cmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRp b24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXIN Cg0KT24gVHVlLCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8aGVuay5i aXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZT4+IHdyb3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFudGljcyB3 b3VsZCAidXNhZ2UiIHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEgImludGVu ZCIsICJhdWRpZW5jZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNwZWNpZmll cyB0aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0 b2tlbiB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBh IHNlY3VyaXR5IGV2ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoNCkkgZG9u J3Qga25vdyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0KDQoNCg0K DQpIZW5rDQoNCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIHdyb3RlOg0KVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsg dGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dlIGNhbuKA mXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkg ZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBh bmQgZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBj bGFpbeKAnSBhcHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3Bl YyBjYW7igJl0IGJlIG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3 SXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhl IOKAnGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBX aGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdu b3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5n IE4gZGlmZmVyZW50IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCd IGNsYWltcy4NCg0KKzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFk ZXIgcGFyYW1ldGVyLg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCklkZW50 aXR5IFNlcnZpY2VzDQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBI YXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4N CipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1hcml1cyBT Y3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPj4NCipDYzogKkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbT4+LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0 YWtlLmpwPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0 bzppZC1ldmVudEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6IFtJZC1l dmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0 IFNFVCBpc3N1ZXINCg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBk aXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4gMTIsIDIw MTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1h aWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29t PG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9y IHRoZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUg aXMgZGVzY3JpYmVkIGJ5ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBt aXRpZ2F0aW9uIGlzIGluICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBS dWxlcyBmb3INCiAgICBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNl IGRpZmZlcmVudCBzZXRzIG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJl bnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZl cmVudCBpc3N1ZXJzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGls bCB0aGluayB0aGF0IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkg YW5kDQogICAgc2FmZXR5Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIw MTcgYXQgOTo1OSBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtl IGFuZCBJIGp1c3QgcHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9z ZWxmLWlzc3VlZC5pbmZvLz9wPTE2OTANCg0KICAgICAgICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0 IDk6MDIgUE0gQWRhbSBEYXdlcyA8YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29n bGUuY29tPg0KICAgICAgICA8bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbT4+PiB3cm90ZToNCg0KICAgICAgICAgICAgSSB3YXMgaW5pdGlhbGx5IGEgZmFu IG9mIGtlZXBpbmcgU0VUUyB0byBiZSB2ZXJ5IHNpbWlsYXIgdG8NCiAgICAgICAgICAgIGlkIHRv a2VucyBidXQgSSBub3cgdGhpbmsgdGhpcyBpcyBhIGJldHRlciBwbGFuLg0KDQogICAgICAgICAg ICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgPG5vdkBtYXRha2Uu anA8bWFpbHRvOm5vdkBtYXRha2UuanA+DQogICAgICAgICAgICA8bWFpbHRvOm5vdkBtYXRha2Uu anA8bWFpbHRvOm5vdkBtYXRha2UuanA+Pj4gd3JvdGU6DQoNCiAgICAgICAgICAgICAgICArMSBl c3BlY2lhbGx5IGZvciAidHlwZSINCg0KICAgICAgICAgICAgICAgIDIwMTctMDYtMDkgMTA6MzIg R01UKzA5OjAwIFBoaWwgSHVudCAoSURNKQ0KICAgICAgICAgICAgICAgIDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+IDxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4+Og0KDQogICAgICAgICAgICAg ICAgICAgICsxDQoNCiAgICAgICAgICAgICAgICAgICAgUGhpbA0KDQoNCiAgICAgICAgICAgICAg ICAgICAgID4gT24gSnVuIDgsIDIwMTcsIGF0IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3UNCiAg ICAgICAgICAgICAgICAgICAgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tPg0KICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4+IHdyb3RlOg0KICAgICAgICAg ICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBUaGVyZSB3ZXJlIGEgY291cGxl IG9mIHByb3Bvc2FscyBvbiBob3cgdG8NCiAgICAgICAgICAgICAgICAgICAgZGlzdGluZ3Vpc2gg U0VUcyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBpbg0KICAgICAgICAgICAgICAg ICAgICBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90DQogICAg ICAgICAgICAgICAgICAgIGNvbmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2Vj dXJpdHkNCiAgICAgICAgICAgICAgICAgICAgdnVsbmVyYWJpbGl0aWVzLg0KICAgICAgICAgICAg ICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBUaGVyZSBpcyBhbHNvIGFub3RoZXIg aW1wb3J0YW50IHJlcXVpcmVtZW50OiB0aGUNCiAgICAgICAgICAgICAgICAgICAgU0VUIGlzc3Vl ciBpbiBzb21lIGNhc2VzIG11c3QgYmUgZGlmZmVyZW50IGZyb20gdGhlDQogICAgICAgICAgICAg ICAgICAgICJzdWIiIGlzc3Vlci4gVGhpcyBpcyB0aGUgY2FzZSBvZiBhbiBSUCBzZW5kaW5nIFNF VHMNCiAgICAgICAgICAgICAgICAgICAgdG8gYW4gSWRQLg0KICAgICAgICAgICAgICAgICAgICAg Pg0KICAgICAgICAgICAgICAgICAgICAgPiBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5k IEkgcHJvcG9zZSB0aGUNCiAgICAgICAgICAgICAgICAgICAgZm9sbG93aW5nOg0KICAgICAgICAg ICAgICAgICAgICAgPiAtIGJvdGggInN1YiIgYW5kICJpc3MiIHRvIGJlIGRlZmluZWQgYXQgdGhl IGV2ZW50DQogICAgICAgICAgICAgICAgICAgIGxldmVsDQogICAgICAgICAgICAgICAgICAgICA+ IC0gImlzcyIgYXQgZXZlbnQgbGV2ZWwgYW5kIGF0IHRvcCBTRVQgbGV2ZWwgY2FuDQogICAgICAg ICAgICAgICAgICAgIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3Mi IGFuZCAic3ViIiBhdCBldmVudCBsZXZlbCBjYW4gYmUgZGlmZmVyZW50DQogICAgICAgICAgICAg ICAgICAgIGFjcm9zcyBldmVudHMgaW4gdGhlIHNhbWUgU0VUDQogICAgICAgICAgICAgICAgICAg ICA+IC0gInN1YiIgc2hvdWxkIE5PVCBiZSBwcmVzZW50IGF0IHRoZSB0b3AgU0VUDQogICAgICAg ICAgICAgICAgICAgIGxldmVsICh0aGlzIHNvbHZlcyB0aGUgZGlzYW1iaWd1YXRpb24pLCBwbGVh c2Ugbm90ZQ0KICAgICAgICAgICAgICAgICAgICAic2hvdWxkIiBhbmQgbm90ICJtdXN0Ig0KICAg ICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBUaGlzIHNvbHV0aW9u IGFsc28gYWxsb3dzIGRpZmZlcmVudCBwcm9maWxlcyB0aGF0DQogICAgICAgICAgICAgICAgICAg IGRlZmluZSBldmVudCB0eXBlcyB0byBkZWZpbmUgYWRkaXRpb25hbCBjbGFpbXMNCiAgICAgICAg ICAgICAgICAgICAgcmVsYXRlZCB0byBzdWIgKGxpa2UgZW1haWwgb3IgcGhvbmVfbnVtYmVyKSBh bmQNCiAgICAgICAgICAgICAgICAgICAgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3aWxsIGJlIGF0 IHRoZSBldmVudCBsZXZlbA0KICAgICAgICAgICAgICAgICAgICB0aGVyZSB3aWxsIGJlIG5vIGNv bGxpc2lvbnMgb3IgYW1iaWd1aXR5Lg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAg ICAgICAgICAgICAgPiBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRv DQogICAgICAgICAgICAgICAgICAgIGRlZmluZSBhIGNvbXBvc2l0ZSAiYXVkIiBjbGFpbS4gVGhp cyBpcyBub3Qgc29sdmluZw0KICAgICAgICAgICAgICAgICAgICB0aGUgcmVxdWlyZW1lbnQgZm9y IGEgZGlzdGluY3QgIFNFVCBpc3N1ZXIuIEFsc28sDQogICAgICAgICAgICAgICAgICAgIGhhdmlu ZyB0aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4DQogICAgICAgICAg ICAgICAgICAgIGluIGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lv bi4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5kIHll dCBhbm90aGVyIHByb3Bvc2FsIHdhcyB0byBpbnRyb2R1Y2UgYSBuZXcNCiAgICAgICAgICAgICAg ICAgICAgY2xhaW0gZm9yIEpXVHMgdGhhdCBkZWZpbmVzIGEgInR5cGUiLiBUaGlzIGlzIG5vdA0K ICAgICAgICAgICAgICAgICAgICBwcmFjdGljYWwgaW4gdGhlIHNob3J0IHRlcm0sIGFuZCBpdCBh bHNvIGlzIG5vdA0KICAgICAgICAgICAgICAgICAgICBzb2x2aW5nIHRoZSBkaXN0aW5jdCBpc3N1 ZXIgcmVxdWlyZW1lbnQsIGJ1dCBJIHRoaW5rDQogICAgICAgICAgICAgICAgICAgIHRoaXMgaXMg c29tZXRoaW5nIHRoZSBKV1QgZ3JvdXAgc2hvdWxkIHNlcmlvdXNseQ0KICAgICAgICAgICAgICAg ICAgICBjb25zaWRlci4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAg ICAgID4gVGhvdWdodHM/DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAg ICAgICA+IE1hcml1cw0KDQogICAgICAgICAgICAgICAgICAgICA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgICAgICA+IElk LWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAg ICAgICAgICAgICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJ Q0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTVi aVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1KbXV1dEJ4NERBUHA3NEFV TGN4MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJnM9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZ S09DZDBteFBRRkpMaHhXSSZlPQ0KDQogICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgICAgIElk LWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQogICAgICAgICAgICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAg ICAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICBJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCiAgICAgICAgICAgIC0tDQogICAg ICAgICAgICBBZGFtIERhd2VzIHwgU3IuIFByb2R1Y3QgTWFuYWdlciB8YWRhd2VzQGdvb2dsZS5j b208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPg0KICAgICAgICAgICAgPG1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+PiB8KzEgNjUwLTIxNC0yNDEwPHRl bDolMkIxJTIwNjUwLTIxNC0yNDEwPg0KICAgICAgICAgICAgPHRlbDooNjUwKSUyMDIxNC0yNDEw Pg0KDQogICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICBJ ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KICAgICAgICAtLQ0K ICAgICAgICBTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSA8aHR0cDovL2hhcmR0d2FyZS5jb20v PiBtYWlsIGxpc3QgdG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5n IG9uIQ0KDQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJk dHdhcmUuY29tLz4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2lu ZyBvbiENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dA0KDQo= --_000_D3FA82F3E63E4C0B88C418477FDA730Aamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3639A27483122E47BEEDEB6D14C149BE@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6IzAwMjA2MDt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY3NjQyMTA0NDsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjcxMzkzMTI0IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjE4Mzg0OTY0MjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0yNjI5MDUxMzQgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+TWlrZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Zb3VyIGV4cGxh bmF0aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1wcm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNp ZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVuSUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRl c2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFzIGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsIGlz c3Vlcw0KIHdpdGggaXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGUg Y2FsbGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBi ZSBjZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tl bi4gQW55IHBhcnR5IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBo YXMNCiBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+QW55IGZ1dHVyZSBJRCBUb2tlbiBkaXN0cmlidXRpb24gbWV0aG9k IG5lZWRzIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5ObyBvdGhl ciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2UgdGhlICZxdW90O25vbmNl4oCdIGNsYWltLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40 LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhp cyBpcyBvbmx5IGEgc29sdXRpb24gZm9yIElEIFRva2Vucy4gRXZlcnkgb3RoZXIgSldUIHByb2Zp bGUgdGhhdCBjYXJlcyBhYm91dCBkaXNhbWJpZ3VhdGlvbiBoYXMgdG8gaW52ZW50IGl0cyBvd24g c29sdXRpb24gdG8gdGhlIHByb2JsZW0uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XZSBrbm93IGZyb20gZXhwZXJpZW5j ZSB0aGF0IG5hbWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGlu Z3MgdGhhdCBoYXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZl bnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3UgYnJvdWdodCB1cCBKV1QNCiBs aWJyYXJpZXM6IGEgZ2VuZXJhbCBzb2x1dGlvbiBhY3R1YWxseSBtYWtlcyBpdCBlYXNpZXIgdG8g dXNlIGNvbW1vbiBsaWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBBIOKAnHVzYWdlLWF3YXJl4oCd IEpXVCBsaWJyYXJ5IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlvbiBmb3IgYW55IEpXVCBwcm9m aWxlLCB3aGVyZWFzIHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBwcm9maWxlIHdvdWxkIHJlcXVp cmUgdW5pcXVlIGxvZ2ljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5uYWJlbGxlIFJp Y2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWRlbnRp dHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj ayI+SWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyBhdCAxOjE2IFBNPGJyPg0KPGI+VG86 IDwvYj5NYXJpdXMgU2N1cnRlc2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7PGJyPg0K PGI+Q2M6IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmlj aGFubmFAYW1hem9uLmNvbSZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50 QGlldGYub3JnJmd0OywgSGVuayBCaXJraG9seiAmbHQ7aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24g Zm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzAwMjA2MCI+WW914oCZdmUgaGVhcmQg b2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4mbmJzcDsgSeKAmWQgY2hhcmFjdGVyaXpl IHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u 4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBs ZXgsIHdpdGhvdXQgZGF0YSBzaG93aW5nDQogdGhlcmXigJlzIGFueSBuZWVkIHRvIGRvIHNvLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOiMwMDIwNjAiPk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2Vk IGluIHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRo YXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZlLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFi bGlzaGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkDQog Zm9yIGFuIElEIFRva2VuIOKAkyBzZWUgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4Lmh0bWwiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4Lmh0 bWw8L2E+LiZuYnNwOyBJZiBwZW9wbGUgaGF2ZSBkYXRhIHNob3dpbmcgdGhhdCB0aGlzIGlzIHBv c3NpYmxlIHdpdGggc3BlY2lmaWMga2luZHMgb2YgQWNjZXNzIFRva2VucyBvciBvdGhlciByZWFs IEpXVCBkZXBsb3ltZW50cywgcGxlYXNlIHByb3ZpZGUgc3BlY2lmaWNzLCBzbyB0aGF0IHdlIGNh biB1c2UgdGhhdCBkYXRhIHRvIGluZm9ybQ0KIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNob2lj ZXMgb24gb3VyIHBhcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzAwMjA2MCI+VGhlIHByb3Bvc2VkIOKAnHNvbHV0 aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0aGUg bm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2aW91 c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4LiZuYnNwOyBZZXMsIHRoZW4g dGhlIHJlc3VsdA0KIGlzIHRoZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1dCBhIGNv bnNlcXVlbmNlIG9mIHRoaXMgaXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxkIGhhdmUg dG8gYmUgdXNlZCwgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiZuYnNwOyBUaGUg bW9yZSB1bndpZWxkeSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2 ZWxvcGVycyBhcmUgdG8ganVzdCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4mbmJz cDsNCiBLZWVwaW5nIGl0IHNpbXBsZSBpcyB0aGUga2V5IHRvIGFkb3B0aW9uLiZuYnNwOyBTdGFu ZGFyZHMgYXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2Nv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+IElkLWV2ZW50 IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVu ZSAxMywgMjAxNyA1OjMzIFBNPGJyPg0KPGI+VG86PC9iPiBNYXJpdXMgU2N1cnRlc2N1ICZsdDtt c2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDtoZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUQgRXZlbnRzIE1haWxpbmcg TGlzdCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb SWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0 aW5jdCBTRVQgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ RWNob2luZyBNYXJpdXPigJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVh biBieSDigJxpbnRlbmTigJ0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VG8geW91ciBmaXJz dCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBL ZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVz IHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1h eQ0KIHJlZmVyIHRvIHdoZW4gZGV0ZXJtaW5pbmcgd2hldGhlciB0byBhY2NlcHQgYSBKV1QgYmVp bmcgcHJlc2VudGVkIHRvIGl0IGluIHNvbWUgY29udGV4dC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZyI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9u IGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5UdWVzZGF5LCBKdW5lIDEzLCAyMDE3IGF0IDExOjA1IEFNPGJyPg0KPGI+VG86IDwvYj5I ZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZSI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj5JRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmciPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24g YW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdW4gMTMs IDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsu Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZCBhIDJuZCBxdWVzdGlvbi48YnI+DQo8YnI+DQpXaGF0IHNlbWFudGljcyB3b3Vs ZCAmcXVvdDt1c2FnZSZxdW90OyBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlh ICZxdW90O2ludGVuZCZxdW90OywgJnF1b3Q7YXVkaWVuY2UmcXVvdDssIGFuZCAmcXVvdDtzY29w ZSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZxdW90O2F1ZCZxdW90OyAoYXVkaWVuY2UpIHNwZWNpZmllcyB0aGUgdGFy Z2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tlbiB0byBh dXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNlY3VyaXR5 IGV2ZW50Pyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+JnF1b3Q7c2NvcGUmcXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IGtub3cgd2hh dCBkbyB5b3UgbWVhbiBieSAmcXVvdDtpbnRlbmQmcXVvdDsgKG9yIGludGVudCk/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCkhlbms8YnI+DQo8 YnI+DQpPbiAwNi8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBwdXR0aW5nIHRo aXMgdG9nZXRoZXIhPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQg aW4gMy45IGFyZSBmbGF3ZWQ6PGJyPg0KPGJyPg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0 IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2Yg dmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0aGlz IHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9hY2gg dG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0 YWtlbiBmb3IgSldUcw0KIGZyb20gYSBjdXJyZW50IHNwZWMuPGJyPg0KPGJyPg0KwrdJdCBpcyB1 bnJlYWxpc3RpYyB0byBleHBlY3QgaW1wbGVtZW50ZXJzIHRvIGFkaGVyZSB0byB0aGUg4oCcZGlm ZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1Rz4oCdIHJ1bGUuIFdoZXRoZXIg bWFuZGF0ZWQgYnkgdGhlIHNwZWMgb3Igbm90LCBpbXBsZW1lbnRlcnMgd2lsbCBpZ25vcmUgdGhp cyBiZWNhdXNlIG1hbmFnaW5nIG9uZSBrZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZm ZXJlbnQga2V5cy48YnI+DQo8YnI+DQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KA nSBjbGFpbXMuPGJyPg0KPGJyPg0KJiM0MzsxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2Xi gJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci48YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KPGJyPg0KSWRlbnRpdHkgU2VydmljZXM8YnI+DQo8 YnI+DQoqRnJvbTogKklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE08YnI+DQoqVG86 ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQoq Q2M6ICpBZGFtIERhd2VzICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7LCAmcXVvdDttYXRha2UsIG5v diZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5r Ij5ub3ZAbWF0YWtlLmpwPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhy ZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGll dGYub3JnPC9hPiZndDssDQogJnF1b3Q7UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KKlN1YmplY3Q6ICpSZTogW0lkLWV2ZW50XSBzb2x1dGlv biBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcjxi cj4NCjxicj4NCkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMgb2YgZGlzY3Vz c2lvbiBvbiB3aGF0IHNob3VsZCBiZSBpbiAzLjkuPGJyPg0KPGJyPg0KT24gTW9uLCBKdW4gMTIs IDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2ZXJ5 IGdvb2QgdGltaW5nIDotKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIGlzc3VlIGlzIGRl c2NyaWJlZCBieSAmcXVvdDsyLjcuIENyb3NzLUpXVCBDb25mdXNpb24mcXVvdDsgYW5kIHRoZTxi cj4NCiZuYnNwOyAmbmJzcDsgbWl0aWdhdGlvbiBpcyBpbiAmcXVvdDszLjkuIFVzZSBNdXR1YWxs eSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3I8YnI+DQombmJzcDsgJm5ic3A7IERpZmZl cmVudCBLaW5kcyBvZiBKV1RzJnF1b3Q7LCBzcGVjaWZpY2FsbHkgJnF1b3Q7VXNlIGRpZmZlcmVu dCBzZXRzIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyByZXF1aXJlZCBjbGFpbXMuLi4mcXVvdDssICZx dW90O1VzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mPGJyPg0KJm5ic3A7 ICZuYnNwOyBKV1RzLiZxdW90OyBhbmQgJnF1b3Q7VXNlIGRpZmZlcmVudCBpc3N1ZXJzIGZvciBk aWZmZXJlbnQga2luZHMgb2YgSldUcy4mcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJ IHN0aWxsIHRoaW5rIHRoYXQgYSAmcXVvdDt0eXBlJnF1b3Q7IGNsYWltIHdvdWxkIGJyaW5nIGEg bG90IG9mIGNsYXJpdHkgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyBzYWZldHkuPGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIFRo dSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5j b208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBZ YXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5m by8/cD0xNjkwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTY5 MDwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4g OCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGF3 ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDsm Z3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMgdG8gYmUgdmVyeSBz aW1pbGFyIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg aWQgdG9rZW5zIGJ1dCBJIG5vdyB0aGluayB0aGlzIGlzIGEgYmV0dGVyIHBsYW4uPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4g OCwgMjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1h dGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+Jmd0OyZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOzEgZXNwZWNpYWxseSBmb3IgJnF1b3Q7dHlwZSZxdW90 Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgMjAxNy0wNi0wOSAxMDozMiBHTVQmIzQzOzA5OjAwIFBoaWwgSHVudCAoSURN KTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPiZndDsmZ3Q7Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOzE8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgUGhpbDxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNj dXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUgd2VyZSBhIGNvdXBs ZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRpc3Rpbmd1aXNoIFNF VHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2VzcyBUb2tlbnMgaW48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg c3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBjb25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHZ1bG5lcmFiaWxpdGllcy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoZXJlIGlzIGFsc28gYW5vdGhlciBp bXBvcnRhbnQgcmVxdWlyZW1lbnQ6IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTRVQgaXNzdWVyIGlu IHNvbWUgY2FzZXMgbXVzdCBiZSBkaWZmZXJlbnQgZnJvbSB0aGU8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JnF1b3Q7c3ViJnF1b3Q7IGlzc3Vlci4gVGhpcyBpcyB0aGUgY2FzZSBvZiBhbiBSUCBzZW5kaW5n IFNFVHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gYW4gSWRQLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgV2l0aCB0aGVzZSByZXF1aXJlbWVu dHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvbGxvd2luZzo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtIGJvdGggJnF1b3Q7c3ViJnF1b3Q7IGFuZCAmcXVv dDtpc3MmcXVvdDsgdG8gYmUgZGVmaW5lZCBhdCB0aGUgZXZlbnQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg bGV2ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O2lzcyZxdW90OyBhdCBl dmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBsZXZlbCBjYW48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmUg ZGlmZmVyZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSAmcXVvdDtpc3MmcXVvdDsg YW5kICZxdW90O3N1YiZxdW90OyBhdCBldmVudCBsZXZlbCBjYW4gYmUgZGlmZmVyZW50PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGFjcm9zcyBldmVudHMgaW4gdGhlIHNhbWUgU0VUPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsgLSAmcXVvdDtzdWImcXVvdDsgc2hvdWxkIE5PVCBiZSBwcmVzZW50IGF0 IHRoZSB0b3AgU0VUPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxldmVsICh0aGlzIHNvbHZlcyB0aGUgZGlz YW1iaWd1YXRpb24pLCBwbGVhc2Ugbm90ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzaG91bGQm cXVvdDsgYW5kIG5vdCAmcXVvdDttdXN0JnF1b3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGlzIHNvbHV0aW9uIGFsc28gYWxsb3dz IGRpZmZlcmVudCBwcm9maWxlcyB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlZmluZSBldmVudCB0 eXBlcyB0byBkZWZpbmUgYWRkaXRpb25hbCBjbGFpbXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRl ZCB0byBzdWIgKGxpa2UgZW1haWwgb3IgcGhvbmVfbnVtYmVyKSBhbmQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3aWxsIGJlIGF0IHRoZSBldmVudCBsZXZlbDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB0aGVyZSB3aWxsIGJlIG5vIGNvbGxpc2lvbnMgb3IgYW1iaWd1aXR5Ljxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg QW5vdGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bzxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBkZWZpbmUgYSBjb21wb3NpdGUgJnF1b3Q7YXVkJnF1b3Q7IGNsYWltLiBUaGlzIGlzIG5v dCBzb2x2aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSByZXF1aXJlbWVudCBmb3IgYSBkaXN0aW5j dCZuYnNwOyBTRVQgaXNzdWVyLiBBbHNvLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoYXZpbmcgdGhlIHNh bWUgY2xhaW0gbmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRheDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp biBkaWZmZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBBbmQgeWV0 IGFub3RoZXIgcHJvcG9zYWwgd2FzIHRvIGludHJvZHVjZSBhIG5ldzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBjbGFpbSBmb3IgSldUcyB0aGF0IGRlZmluZXMgYSAmcXVvdDt0eXBlJnF1b3Q7LiBUaGlzIGlz IG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcmFjdGljYWwgaW4gdGhlIHNob3J0IHRlcm0sIGFuZCBp dCBhbHNvIGlzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzb2x2aW5nIHRoZSBkaXN0aW5jdCBpc3N1 ZXIgcmVxdWlyZW1lbnQsIGJ1dCBJIHRoaW5rPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoaXMgaXMgc29t ZXRoaW5nIHRoZSBKV1QgZ3JvdXAgc2hvdWxkIHNlcmlvdXNseTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBj b25zaWRlci48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7IFRob3VnaHRzPzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsgTWFyaXVzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KSWQtZXZlbnRAaWV0Zi5vcmc8L2E+ ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhx bWcmYW1wO3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7 ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVu dCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kw NTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdr JmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1wO3M9 NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT08L2E+PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBs aXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5JZC1ldmVudEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEFkYW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHw8YSBocmVmPSJtYWlsdG86YWRh d2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT48YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bn b29nbGUuY29tPC9hPiZndDsgfDxhIGhyZWY9InRlbDolMkIxJTIwNjUwLTIxNC0yNDEwIiB0YXJn ZXQ9Il9ibGFuayI+JiM0MzsxIDY1MC0yMTQtMjQxMDwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0idGVsOig2NTApJTIwMjE0LTI0 MTAiPnRlbDooNjUwKSUyMDIxNC0yNDEwPC9hPiZndDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYu b3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSA8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdB UkUgJmx0OzxhIGhyZWY9Imh0dHA6Ly9oYXJkdHdhcmUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9oYXJkdHdhcmUuY29tLzwvYT4mZ3Q7IG1haWwgbGlzdCB0bzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJE VFdBUkUgJmx0OzxhIGhyZWY9Imh0dHA6Ly9oYXJkdHdhcmUuY29tLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvYT4mZ3Q7IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBw cm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D3FA82F3E63E4C0B88C418477FDA730Aamazoncom_-- From nobody Wed Jun 14 17:33:31 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B69126557 for ; Wed, 14 Jun 2017 17:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KNJuxaxK0Ki for ; Wed, 14 Jun 2017 17:33:25 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DC91205D3 for ; Wed, 14 Jun 2017 17:33:25 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5F0XHQK018526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Jun 2017 00:33:18 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5F0XHpS007813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Jun 2017 00:33:17 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5F0XFcP020918; Thu, 15 Jun 2017 00:33:15 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jun 2017 17:33:14 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-3EB15753-1195-4714-AA3E-87A66AD58BBE Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 14 Jun 2017 17:33:12 -0700 Cc: Mike Jones , Marius Scurtescu , ID Events Mailing List , Henk Birkholz Content-Transfer-Encoding: 7bit Message-Id: <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> To: "Richard Backman, Annabelle" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 00:33:29 -0000 --Apple-Mail-3EB15753-1195-4714-AA3E-87A66AD58BBE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >=20 > Mike, > =20 > Your explanation for why this is a non-problem is dependent upon side effe= cts of elements of OpenID Connect that were not designed to solve this issue= . As a result, I see several issues with it: > 1. The caller of the Token Endpoint is the only party that can be ce= rtain that a nonce-less ID Token is really an ID Token. Any party that the c= aller passes the ID Token off to has no way to verify its provenance. > 2. Any future ID Token distribution method needs to solve this probl= em again. > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > 4. This is only a solution for ID Tokens. Every other JWT profile tha= t cares about disambiguation has to invent its own solution to the problem. > =20 > We know from experience that naming collisions and replay attacks are both= things that happen. What=E2=80=99s being proposed is a simple, defensive me= asure against these risks. You brought up JWT libraries: a general solution a= ctually makes it easier to use common libraries for JWT parsing. A =E2=80=9C= usage-aware=E2=80=9D JWT library could handle disambiguation for any JWT pro= file, whereas with the status quo each profile would require unique logic. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Mike Jones > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > Cc: "Richard Backman, Annabelle" , ID Events Mailing L= ist , Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2=80= =99d characterize the proposals in this thread as =E2=80=9Cpremature pessima= tion=E2=80=9D =E2=80=93 making things that can and should be simple complex,= without data showing there=E2=80=99s any need to do so. > =20 > Mandatory solutions are being proposed in this thread to problems that the= re=E2=80=99s no evidence that we actually even have. It=E2=80=99s already b= een established that it=E2=80=99s impossible for a SET to be confused for an= ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/curre= nt/msg00428.html. If people have data showing that this is possible with sp= ecific kinds of Access Tokens or other real JWT deployments, please provide s= pecifics, so that we can use that data to inform appropriate engineering cho= ices on our part. > =20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2= =80=9Csub=E2=80=9D in the normal way, or requiring a type claim, would make p= reviously simple things unnecessarily complex. Yes, then the result is then= different than a normal JWT but a consequence of this is that custom parsin= g code would have to be used, rather than a standard JWT parser. The more u= nwieldy we make it to use SETs, the more likely developers are to just creat= e their own data structures. Keeping it simple is the key to adoption. Sta= ndards are only useful if they are actually used. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Bac= kman, Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu ; Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80= =9Cintend=E2=80=9D? > =20 > To your first question, I think a better analogy would be the X.509 Key Us= age extension: a multi-valued property that declares the intended purpose of= the JWT, and that a recipient may refer to when determining whether to acce= pt a JWT being presented to it in some context. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Marius Scurtescu <= mscurtescu@google.com> > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via "intend= ", "audience", and "scope"? > =20 > "aud" (audience) specifies the target client, but not the intended usage (= access token to authorize resource access or SET to communicate a security e= vent?) > =20 > "scope" is not used by SET. > =20 > I don't know what do you mean by "intend" (or intent)? > =20 > =20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutual= ly exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ens= ure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a= current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cd= ifferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is e= asier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header pa= rameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event on behalf of Dick Hardt > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID Ev= ents Mailing List , "Phil Hunt (IDM)" > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and disti= nct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be in 3= .9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: >=20 > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YK= OCd0mxPQFJLhxWI&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j= 746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D= =20 --Apple-Mail-3EB15753-1195-4714-AA3E-87A66AD58BBE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Phil

On Jun 14, 2017= , at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

= Mike,

=  

= Your explanation for why this is a non-problem is dependent upon side effect= s of elements of OpenID Connect that were not designed to solve this issue. A= s a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can be c= ertain that a nonce-less ID Token is really an ID Token. Any party that the c= aller passes the ID Token off to has no way to verify its provenance.

2.       Any future ID Token distribution method needs to solve this prob= lem again.

3.      No other profile of JWT can ever use the "nonce=E2=80=9D claim.<= /span>

4.      This is only a solution for ID Tokens. Every other JWT profile t= hat cares about disambiguation has to invent its own solution to the problem= .

=  

= We know from experience that naming collisions and replay attacks are both t= hings that happen. What=E2=80=99s being proposed is a simple, defensive meas= ure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common librar= ies for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handl= e disambiguation for any JWT profile, whereas with the status quo each profi= le would require unique logic.

=  

-- 

Annabelle Richard Backman

Identity Services

=  

=  

From:= Id-event <id-event-bounces@ietf.org> on behal= f of Mike Jones <Michael.J= ones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <msc= urtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<= /a>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

You= =E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D.  I=E2=80= =99d characterize the proposals in this thread as =E2=80=9Cpremature pessima= tion=E2=80=9D =E2=80=93 making things that can and should be simple complex,= without data showing there=E2=80=99s any need to do so.

&nb= sp;

Man= datory solutions are being proposed in this thread to problems that there=E2= =80=99s no evidence that we actually even have.  It=E2=80=99s already b= een established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.&nb= sp; If people have data showing that this is possible with specific kinds of= Access Tokens or other real JWT deployments, please provide specifics, so t= hat we can use that data to inform appropriate engineering choices on our part.

&nb= sp;

The= proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80= =9Csub=E2=80=9D in the normal way, or requiring a type claim, would make pre= viously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this is that custo= m parsing code would have to be used, rather than a standard JWT parser.&nbs= p; The more unwieldy we make it to use SETs, the more likely developers are t= o just create their own data structures.  Keeping it simple is the key to adoption.  Standards are only useful i= f they are actually used.

&nb= sp;

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

 

From: Id-= event [mailto:id-event-bounces@= ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <msc= urtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <i= d-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

= Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80=9C= intend=E2=80=9D?

=  

= To your first question, I think a better analogy would be the X.509 Key Usag= e extension: a multi-valued property that declares the intended purpose of t= he JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in s= ome context.

=  

-- 

Annabelle Richard Backman

Identity Services

=  

=  

From:= Id-event <id-event-bounces@ietf.org> on behal= f of Marius Scurtescu <mscurtesc= u@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <i= d-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birk= holz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend",= "audience", and "scope"?

 

"aud" (audience) specifies the target client, but not= the intended usage (access token to authorize resource access or SET to com= municate a security event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by "intend" (or intent)= ?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutually= exclusive set of valid claims and/or header parameters, and enforcing this r= equires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure= that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdif= ferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by t= he spec or not, implementers will ignore this because managing one key is ea= sier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header para= meter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <= adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9= .

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.c= om>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the     mitigation is in "3.9. Use Mutually Exclusive Validation Rules= for
    Different Kinds of JWTs", specifically "Use different sets of<= br>     required claims...", "Use different keys for different kinds o= f
    JWTs." and "Use different issuers for different kinds of JWTs.= ".

    I still think that a "type" claim would bring a lot of clarity= and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID for J= WT
        http:= //self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com         <mailto:adawes@google.com>> wrote:

            I was initially a fan of keeping S= ETS to be very similar to
            id tokens but I now think this is a= better plan.

            On Thu, Jun 8, 2017 at 6:56 PM mat= ake, nov <nov@matake.j= p
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "t= ype"

                2017-06-09 10:32 GMT= +09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailt= o:phil.hunt@oracle= .com>>:

                    +1
=
                    Phil

                     = > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <mscurtescu@google.c= om

              &nbs= p;     <mailto:mscurtescu@google.com>> wrote:
                     = >
                     = > There were a couple of proposals on how to
                    distin= guish SETs from Id Tokens and Access Tokens in
                    such a= way that naive implementations will not
                    confus= e one for the other and open up security
                    vulner= abilities.
                     = >
                     = > There is also another important requirement: the
                    SET is= suer in some cases must be different from the
                    "sub" i= ssuer. This is the case of an RP sending SETs
                    to an I= dP.
                     = >
                     = > With these requirements in mind I propose the
                    follow= ing:
                     = > - both "sub" and "iss" to be defined at the event
                    level<= br>                      = > - "iss" at event level and at top SET level can
                    be dif= ferent
                     = > - "iss" and "sub" at event level can be different
                    across= events in the same SET
                     = > - "sub" should NOT be present at the top SET
                    level (= this solves the disambiguation), please note
                    "shoul= d" and not "must"
                     = >
                     = > This solution also allows different profiles that
                    define= event types to define additional claims
                    relate= d to sub (like email or phone_number) and
                    since a= ll these claims will be at the event level
                    there w= ill be no collisions or ambiguity.
                     = >
                     = > Another proposal (which I supported) was to
                    define= a composite "aud" claim. This is not solving
                    the re= quirement for a distinct  SET issuer. Also,
                    having= the same claim name having different syntax
                    in dif= ferent token types could lead to confusion.
                     = >
                     = > And yet another proposal was to introduce a new
                    claim f= or JWTs that defines a "type". This is not
                    practi= cal in the short term, and it also is not
                    solvin= g the distinct issuer requirement, but I think
                    this i= s something the JWT group should seriously
                    consid= er.
                     = >
                     = > Thoughts?
                     = >
                     = > Marius

                     = > _______________________________________________
                     = > Id-event mailing list

      &= nbsp;              > Id-event@ietf.org <mailto:Id-event@ietf.org>
                     = >
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_= listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk= KY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuut= Bx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKO= Cd0mxPQFJLhxWI&e=3D

                    ______= _________________________________________
                    Id-eve= nt mailing list
                    Id-event@ietf.org <m= ailto:Id-event@ietf.o= rg>
                    https://www.ietf.org/mailman/listinfo/id-event

                ____________________= ___________________________
                Id-event mailing lis= t
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product Manager |= adawes@google.com=
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            __________________________________= _____________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.c= om/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 

= --Apple-Mail-3EB15753-1195-4714-AA3E-87A66AD58BBE-- From nobody Thu Jun 15 10:10:16 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03284127136 for ; Thu, 15 Jun 2017 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX-l-ks_4ywF for ; Thu, 15 Jun 2017 10:10:10 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408F3126D73 for ; Thu, 15 Jun 2017 10:10:10 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id m47so14496488iti.0 for ; Thu, 15 Jun 2017 10:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sGZfMLhOsZBhh//H3w5Ng39vu231m2b7jeN6zXPU9oI=; b=I6QaLJnGpV6KgtU+uX+vMecmM77E705qzR+Kxe8R3ZXOR4cyk9xABw9QXiFSrN1+EQ fz+8ihFakoEJUysVsbR64BROuEXti8sPYIwiNPVFbakHQ4GTKkc5Fma8E5fSNW8Xk5/D KFvB8wLSzg3PeKpSdSCpMZ09ZLDgaAuFixj4pdZdVgy7rLKo7cIbu3ISlLTX2il9er9g zfJt4UTEM1whCNqatS9jSAD3fnNSMAwio7UC3E+GaOW107NuMrPvPFwHLH1fXHTsNRJH /qBh8OHjVCa1mRocEy2yRq0svok88oi5FQqxTabK3i9P7Z0qlryvcK82+/8WpMRMXWPH y6gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sGZfMLhOsZBhh//H3w5Ng39vu231m2b7jeN6zXPU9oI=; b=BNULxgELyAkeUw/aaCCKEBPjOIuH5xY0c4UFHLD4fczGHErtgd0k8p1wWabPlJghUI UOt5E5IRUUjq87mG/DzHFUaKWxy4RkRhgau0/ZeTf5/W5fumG7EFkPcmCENRBXJjRF15 P8gniVGkrN/OKJfdToxekXPcEwMiTH3BOUBi1KnzokcSY0FUU78x9S0B2mdPu3sHsSUK COtuFla6Dg2vAdoMPPwD5qlWhVm12E5Y2VfLis8Kcf1077HUJ6t2wdDM/rVFWBOpjR58 8df8HqRb5IIDv6ONSaW+E+Lf5UH4ODLZh23eKNOIZ6wN+czrlyazKFYsbzmtsQjs/nvc 17Kw== X-Gm-Message-State: AKS2vOxK5VOsaEhrs2Sq0Lj7Lf0/lIpg3tjl5n6UgYEc59+IkqA+gheZ fsdqhxryhUNbDkysz1jkhIOHxJxpm8fzWso= X-Received: by 10.36.27.72 with SMTP id 69mr6701923its.116.1497546609265; Thu, 15 Jun 2017 10:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.36 with HTTP; Thu, 15 Jun 2017 10:09:48 -0700 (PDT) In-Reply-To: <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> From: Marius Scurtescu Date: Thu, 15 Jun 2017 10:09:48 -0700 Message-ID: To: "Phil Hunt (IDM)" Cc: "Richard Backman, Annabelle" , Mike Jones , ID Events Mailing List , Henk Birkholz Content-Type: multipart/alternative; boundary="001a114495b6ae744a055202bd75" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:10:15 -0000 --001a114495b6ae744a055202bd75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to what Annabelle said. Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case. Marius On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wrote: > +1 > > Phil > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id- > 2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > --001a114495b6ae744a055202bd75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to what Annabelle said.

Also, Mike y= ou are missing the other requirement, for RPs to send events to an IdP. The= iss+sub pair at the top level is broken in this case.

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (= IDM) <phil.hunt@oracle.com> wrote:
+1

Phil

On Jun 14, 2017, at 5:25= PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Mike,

=C2=A0

Your explanation for why this is a non-problem is dependent upon side effe= cts of elements of OpenID Connect that were not designed to solve this issu= e. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T= he caller of the Token Endpoint is the only party that can be certain that = a nonce-less ID Token is really an ID Token. Any party that the caller pass= es the ID Token off to has no way to verify its provenance.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A= ny future ID Token distribution method needs to solve this problem again.

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N= o other profile of JWT can ever use the "nonce=E2=80=9D claim.<= span style=3D"font-family:Calibri">

4.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T= his is only a solution for ID Tokens. Every other JWT profile that cares ab= out disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and replay attacks are both= things that happen. What=E2=80=99s being proposed is a simple, defensive m= easure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libra= ries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could han= dle disambiguation for any JWT profile, whereas with the status quo each pr= ofile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

F= rom: Id-event <id-event-bounces@ietf.= org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events = Mailing List <id-= event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Yo= u=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2= =80=99d characterize the proposals in this thread as =E2=80=9Cpremature pes= simation=E2=80=9D =E2=80=93 making things that can and should be simple com= plex, without data showing there=E2=80=99s any need to do so.

= =C2=A0

Ma= ndatory solutions are being proposed in this thread to problems that there= =E2=80=99s no evidence that we actually even have.=C2=A0 It=E2=80=99s alrea= dy been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.h= tml.=C2=A0 If people have data showing that this is possible with speci= fic kinds of Access Tokens or other real JWT deployments, please provide sp= ecifics, so that we can use that data to inform appropriate engineering choices on our part.

= =C2=A0

Th= e proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2= =80=9Csub=E2=80=9D in the normal way, or requiring a type claim, would make= previously simple things unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT but a consequence of this is that cust= om parsing code would have to be used, rather than a standard JWT parser.= =C2=A0 The more unwieldy we make it to use SETs, the more likely developers= are to just create their own data structures.=C2=A0 Keeping it simple is the key to adoption.=C2=A0 Standards are only useful = if they are actually used.

= =C2=A0

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

=C2=A0

From: I= d-event [mai= lto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80= =9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better analogy would be the X.509 Key Us= age extension: a multi-valued property that declares the intended purpose o= f the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in= some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

F= rom: Id-event <id-event-bounces@ietf.= org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank">henk.bi= rkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target clie= nt, but not the intended usage (access token to authorize resource access o= r SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.<= /p>

=C2=A0

I don't know what do you mean by "intend&qu= ot; (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com<= /a>>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing Li= st <id-event@ietf= .org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:= mscurtescu@googl= e.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank">adawes@google.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake= .jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com <mai= lto:phil.hunt@ora= cle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank">mscurtescu@google= .com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:mscurtescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxP= EivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6mi= RiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&a= mp;e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <= ;mailto:Id-event@iet= f.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtw= are.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event

=C2=A0


--001a114495b6ae744a055202bd75-- From nobody Thu Jun 15 12:08:47 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683E41293EE for ; Thu, 15 Jun 2017 12:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUl7uz6Fe5M1 for ; Thu, 15 Jun 2017 12:08:35 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFF31293F2 for ; Thu, 15 Jun 2017 12:08:34 -0700 (PDT) X-AuditID: 12074424-585ff700000002e1-20-5942db30fdcf Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DF.2A.00737.13BD2495; Thu, 15 Jun 2017 15:08:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5FJ8ViA019238; Thu, 15 Jun 2017 15:08:32 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5FJ8Rlb018225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2017 15:08:29 -0400 From: Justin Richer Message-Id: <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_6D77A46C-DE33-4312-A31D-06BEF9418500" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 15 Jun 2017 15:08:26 -0400 In-Reply-To: Cc: Phil Hunt , "Richard Backman, Annabelle" , Henk Birkholz , Mike Jones , ID Events Mailing List To: Marius Scurtescu References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsUixCmqrWt42ynSYOEMfouGf39ZLToWdDNZ 7J32icXi1tk1TBYL5jeyW7Q/5nBg81hxoYvVY8GmUo8lS34yebTu+Mvu8fHpLRaPjgc3GAPY orhsUlJzMstSi/TtErgyNr+vKOi5z1xx9f0UtgbGx7OYuxg5OSQETCTmzutjBLGFBBYzSSy7 aNTFyAVkb2SUuPP7ChuE85BJYs+3ZSwgVWwCqhLT17Qwgdi8AlYS36d2gE1iFkiS2PKtlb2L kQMori/R+xxsqLBAhMT/bX1grSxArUe2TgEr5xQIlJi7Zz07yHxmgWYmiVsL7oAViQjoSJzv /MgCsfgyu8T7HWtYIE6Vlbg1+xLzBEb+WUj2zULYBxHWlli28DUzhK0psb97OQumuIZE57eJ rAsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIExQm7i8oOxu4e70OMAhyM Sjy8Cg1OkUKsiWXFlbmHGCU5mJREefnlgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeKfOAcrx piRWVqUW5cOkpDlYlMR5xTUaI4QE0hNLUrNTUwtSi2CyMhwcShK8GreAGgWLUtNTK9Iyc0oQ 0kwcnCDDeYCGT78JMry4IDG3ODMdIn+K0ZhjQc+GL0wcTVu3fGESYsnLz0uVEuedD1IqAFKa UZoHNw2U6hLeHjZ9xSgO9JwwbyFIFQ8wTcLNewW0igloVdAFB5BVJYkIKakGxunSImdq3pY9 jfpUvyZN8HlOr07hV991789fmhDi7yvNfHARP2+Ta8mOxWu3M+tY7ImPuKK3b+bTwjscbZ83 rhRiYpI+9i+ygTnm6bIdLneWfjlzw3RhJz9vo0HOpR7OT/lC+yKuZV++H+P3ptTVYc6R1VPl udSuybfc57Ks9o/jK9voYDPLX4mlOCPRUIu5qDgRAEL0y5tQAwAA Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:08:39 -0000 --Apple-Mail=_6D77A46C-DE33-4312-A31D-06BEF9418500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to this as well. =E2=80=94 Justin > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu = wrote: >=20 > +1 to what Annabelle said. >=20 > Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >=20 > Marius >=20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > +1 >=20 > Phil >=20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >=20 >> Mike, >>=20 >> =20 >>=20 >> Your explanation for why this is a non-problem is dependent upon side = effects of elements of OpenID Connect that were not designed to solve = this issue. As a result, I see several issues with it: >>=20 >> 1. The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance. >>=20 >> 2. Any future ID Token distribution method needs to solve this = problem again. >>=20 >> 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >>=20 >> 4. This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem. >>=20 >> =20 >>=20 >> We know from experience that naming collisions and replay attacks are = both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> Identity Services >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Id-event > on behalf of Mike Jones = > >> Date: Wednesday, June 14, 2017 at 1:16 PM >> To: Marius Scurtescu > >> Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > >> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>=20 >> =20 >>=20 >> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematur= e pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >>=20 >> =20 >>=20 >> Mandatory solutions are being proposed in this thread to problems = that there=E2=80=99s no evidence that we actually even have. It=E2=80=99s= already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >>=20 >> =20 >>=20 >> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use = of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, = would make previously simple things unnecessarily complex. Yes, then = the result is then different than a normal JWT but a consequence of this = is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle >> Sent: Tuesday, June 13, 2017 5:33 PM >> To: Marius Scurtescu >; Henk Birkholz = > >> Cc: ID Events Mailing List > >> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>=20 >> =20 >>=20 >> Echoing Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D? >>=20 >> =20 >>=20 >> To your first question, I think a better analogy would be the X.509 = Key Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context. >>=20 >> =20 >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> Identity Services >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Id-event > on behalf of Marius Scurtescu = > >> Date: Tuesday, June 13, 2017 at 11:05 AM >> To: Henk Birkholz > >> Cc: ID Events Mailing List > >> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>=20 >> =20 >>=20 >> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >>=20 >> And a 2nd question. >>=20 >> What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"? >>=20 >> =20 >>=20 >> "aud" (audience) specifies the target client, but not the intended = usage (access token to authorize resource access or SET to communicate a = security event?) >>=20 >> =20 >>=20 >> "scope" is not used by SET. >>=20 >> =20 >>=20 >> I don't know what do you mean by "intend" (or intent)? >>=20 >> =20 >>=20 >> =20 >>=20 >>=20 >>=20 >> Henk >>=20 >> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>=20 >> Thanks for putting this together! >>=20 >> I think the assumptions inherent in 3.9 are flawed: >>=20 >> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >>=20 >> =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >>=20 >> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >>=20 >> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >>=20 >> --=20 >>=20 >> Annabelle Richard Backman >>=20 >> Identity Services >>=20 >> *From: *Id-event > on behalf of Dick Hardt = > >> *Date: *Monday, June 12, 2017 at 3:18 PM >> *To: *Marius Scurtescu > >> *Cc: *Adam Dawes >, = "matake, nov" >, ID Events Mailing = List >, "Phil Hunt (IDM)" = > >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>=20 >> Agreed. Note that there is still lots of discussion on what should be = in 3.9. >>=20 >> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = = >> wrote: >>=20 >> Thanks for the pointer Dick, very good timing :-) >>=20 >> The issue is described by "2.7. Cross-JWT Confusion" and the >> mitigation is in "3.9. Use Mutually Exclusive Validation Rules = for >> Different Kinds of JWTs", specifically "Use different sets of >> required claims...", "Use different keys for different kinds of >> JWTs." and "Use different issuers for different kinds of JWTs.". >>=20 >> I still think that a "type" claim would bring a lot of clarity = and >> safety. >>=20 >>=20 >> Marius >>=20 >> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >> >> = wrote: >>=20 >> Yaron, Mike and I just published an BCP ID for JWT >> http://self-issued.info/?p=3D1690 = >>=20 >> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >> >> wrote: >>=20 >> I was initially a fan of keeping SETS to be very similar = to >> id tokens but I now think this is a better plan. >>=20 >> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >> >> wrote: >>=20 >> +1 especially for "type" >>=20 >> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >> = >>: >>=20 >> +1 >>=20 >> Phil >>=20 >>=20 >> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> >> >> wrote: >> > >> > There were a couple of proposals on how to >> distinguish SETs from Id Tokens and Access Tokens = in >> such a way that naive implementations will not >> confuse one for the other and open up security >> vulnerabilities. >> > >> > There is also another important requirement: = the >> SET issuer in some cases must be different from = the >> "sub" issuer. This is the case of an RP sending = SETs >> to an IdP. >> > >> > With these requirements in mind I propose the >> following: >> > - both "sub" and "iss" to be defined at the = event >> level >> > - "iss" at event level and at top SET level = can >> be different >> > - "iss" and "sub" at event level can be = different >> across events in the same SET >> > - "sub" should NOT be present at the top SET >> level (this solves the disambiguation), please = note >> "should" and not "must" >> > >> > This solution also allows different profiles = that >> define event types to define additional claims >> related to sub (like email or phone_number) and >> since all these claims will be at the event level >> there will be no collisions or ambiguity. >> > >> > Another proposal (which I supported) was to >> define a composite "aud" claim. This is not = solving >> the requirement for a distinct SET issuer. Also, >> having the same claim name having different = syntax >> in different token types could lead to confusion. >> > >> > And yet another proposal was to introduce a = new >> claim for JWTs that defines a "type". This is not >> practical in the short term, and it also is not >> solving the distinct issuer requirement, but I = think >> this is something the JWT group should seriously >> consider. >> > >> > Thoughts? >> > >> > Marius >>=20 >> > = _______________________________________________ >> > Id-event mailing list >>=20 >> > Id-event@ietf.org = > >> > >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org = > >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org = > >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >> --=20 >> Adam Dawes | Sr. Product Manager |adawes@google.com = >> > |+1 = 650-214-2410 >> > >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org = > >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >> --=20 >> Subscribe to the HARDTWARE > mail list to >> learn about projects I am working on! >>=20 >>=20 >>=20 >> --=20 >>=20 >> Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >> =20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_6D77A46C-DE33-4312-A31D-06BEF9418500 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to this as well.

 =E2=80=94 Justin

On = Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

+1 to what Annabelle said.

Also, Mike you are = missing the other requirement, for RPs to send events to an IdP. The = iss+sub pair at the top level is broken in this case.

Marius

On Wed, Jun 14, 2017 at 5:33 = PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1

Phil
On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

Mike,

 

Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its provenance.

2.       Any future ID Token distribution method needs to solve this = problem again.

3.      No other profile of JWT can ever use the "nonce=E2=80=9D = claim.

4.      This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem.

 

We know from experience that naming collisions and replay = attacks are both things that happen. What=E2=80=99s being proposed is a = simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common = libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library = could handle disambiguation for any JWT profile, whereas with the status = quo each profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity = Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones = <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
= To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

You=E2=80=99ve = heard of =E2=80=9Cpremature optimization=E2=80=9D.  I=E2=80=99d = characterize the proposals in this thread as =E2=80=9Cpremature = pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so.

 

Mandatory = solutions are being proposed in this thread to problems that there=E2=80=99= s no evidence that we actually even have.  It=E2=80=99s already = been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part.

 

The proposed = =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2= =80=9D in the normal way, or requiring a type claim, would make = previously simple things unnecessarily complex.  Yes, then the = result is then different than a normal JWT but a consequence of this is that = custom parsing code would have to be used, rather than a standard JWT = parser.  The more unwieldy we make it to use SETs, the more likely = developers are to just create their own data structures.  Keeping it simple is the key to adoption.  Standards are only = useful if they are actually used.

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

Echoing = Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D?

 

To your first question, I think a better analogy would be the = X.509 Key Usage extension: a multi-valued property that declares the = intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it = in some context.

 

-- 

Annabelle Richard Backman

Identity = Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"?

=

 

"aud" (audience) specifies the = target client, but not the intended usage (access token to authorize = resource access or SET to communicate a security event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by = "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this = together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" = <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in = 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and = the
    mitigation is in "3.9. Use Mutually Exclusive Validation = Rules for
    Different Kinds of JWTs", specifically "Use different sets = of
    required claims...", "Use different keys for different = kinds of
    JWTs." and "Use different issuers for different kinds of = JWTs.".

    I still think that a "type" claim would bring a lot of = clarity and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID = for JWT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes = <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I was initially a fan of = keeping SETS to be very similar to
            id tokens but I now think this = is a better plan.

            On Thu, Jun 8, 2017 at 6:56 PM = matake, nov <nov@matake.jp
            <mailto:nov@matake.jp>> wrote:

                +1 especially = for "type"

                2017-06-09 10:32 = GMT+09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>:

                    = +1

                    = Phil


                    =  > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    = <mscurtescu@google.com

        =             <mailto:mscurtescu@google.com>> wrote:
                    =  >
                    =  > There were a couple of proposals on how to
                    = distinguish SETs from Id Tokens and Access Tokens in
                    = such a way that naive implementations will not
                    = confuse one for the other and open up security
                    = vulnerabilities.
                    =  >
                    =  > There is also another important requirement: the
=                     = SET issuer in some cases must be different from the
                    = "sub" issuer. This is the case of an RP sending SETs
                    to = an IdP.
                    =  >
                    =  > With these requirements in mind I propose the
                    = following:
                    =  > - both "sub" and "iss" to be defined at the event
                    = level
                    =  > - "iss" at event level and at top SET level can
                    be = different
                    =  > - "iss" and "sub" at event level can be different
                    = across events in the same SET
                    =  > - "sub" should NOT be present at the top SET
                    = level (this solves the disambiguation), please note
                    = "should" and not "must"
                    =  >
                    =  > This solution also allows different profiles that
                    = define event types to define additional claims
                    = related to sub (like email or phone_number) and
                    = since all these claims will be at the event level
                    = there will be no collisions or ambiguity.
                    =  >
                    =  > Another proposal (which I supported) was to
                    = define a composite "aud" claim. This is not solving
                    = the requirement for a distinct  SET issuer. Also,
                    = having the same claim name having different syntax
                    in = different token types could lead to confusion.
                    =  >
                    =  > And yet another proposal was to introduce a new
                    = claim for JWTs that defines a "type". This is not
                    = practical in the short term, and it also is not
                    = solving the distinct issuer requirement, but I think
                    = this is something the JWT group should seriously
                    = consider.
                    =  >
                    =  > Thoughts?
                    =  >
                    =  > Marius

                    =  > _______________________________________________
                    =  > Id-event mailing list

  =                   =  > Id-event@ietf.org <mailto:Id-event@ietf.org>
                    =  >
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                    = _______________________________________________
                    = Id-event mailing list
                    Id-event@ietf.org <mailto:Id-event@ietf.org>
                    https://www.ietf.org/mailman/listinfo/id-event

                = _______________________________________________
                Id-event mailing = list
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product = Manager |adawes@google.com
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            = _______________________________________________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> = mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> = mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D

_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_6D77A46C-DE33-4312-A31D-06BEF9418500-- From nobody Sat Jun 17 13:45:18 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB9129BD5 for ; Sat, 17 Jun 2017 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fna-N3PhE_DV for ; Sat, 17 Jun 2017 13:45:11 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99CC8126DD9 for ; Sat, 17 Jun 2017 13:45:10 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id y25so14237471wrd.2 for ; Sat, 17 Jun 2017 13:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=sr/W5F4GdUEHQB0YlrSCC/7wbUYldptxvQmNjnM0+wI=; b=enO5tkAyepdXgiJW7dd5Ts+GHKVIRH9d5o6btWMgQOYImfEh58fOh8GSevS2/jEtwf 16lTmJnFlqy7jPq6/K9Y8FU0fnJw6+d88oIjZ+tjKmkZLrO7APr6GR1dT6161gvVRyV5 a8wxCNEyILFHx8i7OAjQaVA1FubkDtVFk5sOI5UFtL3jQc1tFR3zIqTqwyagD2xsjt2d qmLCM/3FpjBapvxY7dl7r6qBJXknTBfmi2HhmCtOx+LJx1eg2eHRI4oIv2F2cyZUzsIi s/oEvAxC9UnP8AKPadjYrvKSEeaPrUbFKL1yTqY8piE/ZyKq/m8lX1ydyUwBAx0aOE+P Tpbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=sr/W5F4GdUEHQB0YlrSCC/7wbUYldptxvQmNjnM0+wI=; b=pZ9R9JCATqgUbZGm0Qxxj6Vj2T7ZQByyOyCuQm2+e8FVykMQlYmQp6eh0kZA8SOagH VFJbNnQm2Pj/bWNNuYtS9m1DQC+EMjr58ycHGMkY9/qWDMS4lECyKxgbQ97FbvfQ5uGc 21COb4xGOjgzRf9V4Kg0H5poTHibFv7RPr5JIxuch9r/bz6NSyRKfE3DvCDRrIJEaeY+ M6lyk+PNr3HhwF5K13Sa5YlHHVhH69ZoQBKyS0qD/xlF6toPcr7wmj/K0lHKHGEkwO8D 2X9+LTf2xFy9wv8T5L8xuwrUOFvKptsEILGp+I2Ql4P2dmDBfRUC+QU4TL4lqHXdevs0 7omA== X-Gm-Message-State: AKS2vOzjYfVL7oeveWNPEPyQG8NL6c9yTFOGFXkUAO9kAYf/Cl2H+/KW tUEqdsWWWyX46A== X-Received: by 10.223.136.109 with SMTP id e42mr10898487wre.81.1497732308990; Sat, 17 Jun 2017 13:45:08 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-66-161-210.red.bezeqint.net. [109.66.161.210]) by smtp.gmail.com with ESMTPSA id o200sm1615274wmg.22.2017.06.17.13.45.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jun 2017 13:45:08 -0700 (PDT) To: Justin Richer , Marius Scurtescu Cc: "Richard Backman, Annabelle" , Mike Jones , Henk Birkholz , ID Events Mailing List , Phil Hunt References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> From: Yaron Sheffer Message-ID: <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> Date: Sat, 17 Jun 2017 23:45:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> Content-Type: multipart/alternative; boundary="------------58DBD4A5830951D0890901F5" Content-Language: en-US Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 20:45:16 -0000 This is a multi-part message in MIME format. --------------58DBD4A5830951D0890901F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit So to summarize what I'm seeing on this thread: Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec. Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP. Did I miss anything? By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published. Thanks, Yaron On 15/06/17 22:08, Justin Richer wrote: > +1 to this as well. > > — Justin > >> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > > wrote: >> >> +1 to what Annabelle said. >> >> Also, Mike you are missing the other requirement, for RPs to send >> events to an IdP. The iss+sub pair at the top level is broken in this >> case. >> >> Marius >> >> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) >> > wrote: >> >> +1 >> >> Phil >> >> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle >> > wrote: >> >>> Mike, >>> >>> Your explanation for why this is a non-problem is dependent upon >>> side effects of elements of OpenID Connect that were not >>> designed to solve this issue. As a result, I see several issues >>> with it: >>> >>> 1.The caller of the Token Endpoint is the only party that can be >>> certain that a nonce-less ID Token is really an ID Token. Any >>> party that the caller passes the ID Token off to has no way to >>> verify its provenance. >>> >>> 2.Any future ID Token distribution method needs to solve this >>> problem again. >>> >>> 3.No other profile of JWT can ever use the "nonce” claim. >>> >>> 4.This is only a solution for ID Tokens. Every other JWT profile >>> that cares about disambiguation has to invent its own solution >>> to the problem. >>> >>> We know from experience that naming collisions and replay >>> attacks are both things that happen. What’s being proposed is a >>> simple, defensive measure against these risks. You brought up >>> JWT libraries: a general solution actually makes it easier to >>> use common libraries for JWT parsing. A “usage-aware” JWT >>> library could handle disambiguation for any JWT profile, whereas >>> with the status quo each profile would require unique logic. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> Identity Services >>> >>> *From: *Id-event >> > on behalf of Mike Jones >>> > >>> *Date: *Wednesday, June 14, 2017 at 1:16 PM >>> *To: *Marius Scurtescu >> > >>> *Cc: *"Richard Backman, Annabelle" >> >, ID Events Mailing List >>> >, Henk Birkholz >>> >> > >>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion >>> and distinct SET issuer >>> >>> You’ve heard of “premature optimization”. I’d characterize the >>> proposals in this thread as “premature pessimation” – making >>> things that can and should be simple complex, without data >>> showing there’s any need to do so. >>> >>> Mandatory solutions are being proposed in this thread to >>> problems that there’s no evidence that we actually even have. >>> It’s already been established that it’s impossible for a SET to >>> be confused for an ID Token – see >>> https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html >>> . >>> If people have data showing that this is possible with specific >>> kinds of Access Tokens or other real JWT deployments, please >>> provide specifics, so that we can use that data to inform >>> appropriate engineering choices on our part. >>> >>> The proposed “solutions”, such as prohibiting the use of “sub” >>> in the normal way, or requiring a type claim, would make >>> previously simple things unnecessarily complex. Yes, then the >>> result is then different than a normal JWT but a consequence of >>> this is that custom parsing code would have to be used, rather >>> than a standard JWT parser. The more unwieldy we make it to use >>> SETs, the more likely developers are to just create their own >>> data structures. Keeping it simple is the key to adoption. >>> Standards are only useful if they are actually used. >>> >>> -- Mike >>> >>> *From:*Id-event [mailto:id-event-bounces@ietf.org >>> ] *On Behalf Of *Richard >>> Backman, Annabelle >>> *Sent:* Tuesday, June 13, 2017 5:33 PM >>> *To:* Marius Scurtescu >> >; Henk Birkholz >>> >> > >>> *Cc:* ID Events Mailing List >> > >>> *Subject:* Re: [Id-event] solution for Id/Access Token confusion >>> and distinct SET issuer >>> >>> Echoing Marius’s question: can you explain what you mean by >>> “intend”? >>> >>> To your first question, I think a better analogy would be the >>> X.509 Key Usage extension: a multi-valued property that declares >>> the intended purpose of the JWT, and that a recipient may refer >>> to when determining whether to accept a JWT being presented to >>> it in some context. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> Identity Services >>> >>> *From: *Id-event >> > on behalf of Marius >>> Scurtescu > >>> *Date: *Tuesday, June 13, 2017 at 11:05 AM >>> *To: *Henk Birkholz >> > >>> *Cc: *ID Events Mailing List >> > >>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion >>> and distinct SET issuer >>> >>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz >>> >> > wrote: >>> >>> And a 2nd question. >>> >>> What semantics would "usage" provide that that are not >>> covered via "intend", "audience", and "scope"? >>> >>> "aud" (audience) specifies the target client, but not the >>> intended usage (access token to authorize resource access or SET >>> to communicate a security event?) >>> >>> "scope" is not used by SET. >>> >>> I don't know what do you mean by "intend" (or intent)? >>> >>> >>> >>> Henk >>> >>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>> >>> Thanks for putting this together! >>> >>> I think the assumptions inherent in 3.9 are flawed: >>> >>> ·We can’t guarantee that every type of JWT will have a >>> mutually exclusive set of valid claims and/or header >>> parameters, and enforcing this requires a “fail on an >>> unrecognized claim” approach to ensure that JWTs from >>> some future spec can’t be mistaken for JWTs from a >>> current spec. >>> >>> ·It is unrealistic to expect implementers to adhere to >>> the “different keys for different kinds of JWTs” rule. >>> Whether mandated by the spec or not, implementers will >>> ignore this because managing one key is easier than >>> managing N different keys. >>> >>> ·Ditto for “aud” and “iss” claims. >>> >>> +1 for a “type” or “usage” claim/header parameter. >>> >>> -- >>> >>> Annabelle Richard Backman >>> >>> Identity Services >>> >>> *From: *Id-event >> > on behalf of Dick >>> Hardt > >>> *Date: *Monday, June 12, 2017 at 3:18 PM >>> *To: *Marius Scurtescu >> > >>> *Cc: *Adam Dawes >> >, "matake, nov" >>> >, ID Events >>> Mailing List >> >, "Phil Hunt (IDM)" >>> > >>> *Subject: *Re: [Id-event] solution for Id/Access Token >>> confusion and distinct SET issuer >>> >>> Agreed. Note that there is still lots of discussion on >>> what should be in 3.9. >>> >>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu >>> >>> >> >> wrote: >>> >>> Thanks for the pointer Dick, very good timing :-) >>> >>> The issue is described by "2.7. Cross-JWT Confusion" >>> and the >>> mitigation is in "3.9. Use Mutually Exclusive >>> Validation Rules for >>> Different Kinds of JWTs", specifically "Use >>> different sets of >>> required claims...", "Use different keys for >>> different kinds of >>> JWTs." and "Use different issuers for different >>> kinds of JWTs.". >>> >>> I still think that a "type" claim would bring a lot >>> of clarity and >>> safety. >>> >>> >>> Marius >>> >>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>> >>> >> >> wrote: >>> >>> Yaron, Mike and I just published an BCP ID for JWT >>> http://self-issued.info/?p=1690 >>> >>> >>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>> >>> >> >> wrote: >>> >>> I was initially a fan of keeping SETS to be >>> very similar to >>> id tokens but I now think this is a better plan. >>> >>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>> >>> >> >> wrote: >>> >>> +1 especially for "type" >>> >>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>> >> >>> >> >>: >>> >>> +1 >>> >>> Phil >>> >>> >>> > On Jun 8, 2017, at 6:28 PM, >>> Marius Scurtescu >>> >> >>> >>> >> >> wrote: >>> > >>> > There were a couple of proposals on how to >>> distinguish SETs from Id Tokens and Access Tokens in >>> such a way that naive >>> implementations will not >>> confuse one for the other and open up security >>> vulnerabilities. >>> > >>> > There is also another important requirement: the >>> SET issuer in some cases must be >>> different from the >>> "sub" issuer. This is the case of an RP sending SETs >>> to an IdP. >>> > >>> > With these requirements in mind I propose the >>> following: >>> > - both "sub" and "iss" to be defined at the event >>> level >>> > - "iss" at event level and at top SET level can >>> be different >>> > - "iss" and "sub" at event level can be different >>> across events in the same SET >>> > - "sub" should NOT be present at the top SET >>> level (this solves the disambiguation), please note >>> "should" and not "must" >>> > >>> > This solution also allows different profiles that >>> define event types to define additional claims >>> related to sub (like email or phone_number) and >>> since all these claims will be at the event level >>> there will be no collisions or ambiguity. >>> > >>> > Another proposal (which I supported) was to >>> define a composite "aud" claim. This is not solving >>> the requirement for a distinct SET >>> issuer. Also, >>> having the same claim name having different syntax >>> in different token types could lead >>> to confusion. >>> > >>> > And yet another proposal was to introduce a new >>> claim for JWTs that defines a "type". This is not >>> practical in the short term, and it also is not >>> solving the distinct issuer requirement, but I think >>> this is something the JWT group >>> should seriously >>> consider. >>> > >>> > Thoughts? >>> > >>> > Marius >>> >>> > _______________________________________________ >>> > Id-event mailing list >>> >>> > Id-event@ietf.org >>> >> > >>> > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> -- >>> Adam Dawes | Sr. Product Manager >>> |adawes@google.com >>> >> > |+1 650-214-2410 >>> >>> >> > >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >> > >>> mail list to >>> learn about projects I am working on! >>> >>> >>> >>> -- >>> >>> Subscribe to the HARDTWARE >> > >>> mail list to learn about projects I am working on! >>> >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e= >>> >>> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------58DBD4A5830951D0890901F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.

Thanks,

    Yaron


On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well.

 — Justin

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

+1 to what Annabelle said.

Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1

Phil

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Mike,

 

Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.       Any future ID Token distribution method needs to solve this problem again.

3.      No other profile of JWT can ever use the "nonce” claim.

4.      This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

 

We know from experience that naming collisions and replay attacks are both things that happen. What’s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A “usage-aware” JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

You’ve heard of “premature optimization”.  I’d characterize the proposals in this thread as “premature pessimation” – making things that can and should be simple complex, without data showing there’s any need to do so.

 

Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have.  It’s already been established that it’s impossible for a SET to be confused for an ID Token – see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.

 

The proposed “solutions”, such as prohibiting the use of “sub” in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser.  The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key to adoption.  Standards are only useful if they are actually used.

 

                                                -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

Echoing Marius’s question: can you explain what you mean by “intend”?

 

To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?

 

"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

·We can’t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a “fail on an unrecognized claim” approach to ensure that JWTs from some future spec can’t be mistaken for JWTs from a current spec.

·It is unrealistic to expect implementers to adhere to the “different keys for different kinds of JWTs” rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

·Ditto for “aud” and “iss” claims.

+1 for a “type” or “usage” claim/header parameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the
    mitigation is in "3.9. Use Mutually Exclusive Validation Rules for
    Different Kinds of JWTs", specifically "Use different sets of
    required claims...", "Use different keys for different kinds of
    JWTs." and "Use different issuers for different kinds of JWTs.".

    I still think that a "type" claim would bring a lot of clarity and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID for JWT
        http://self-issued.info/?p=1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I was initially a fan of keeping SETS to be very similar to
            id tokens but I now think this is a better plan.

            On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "type"

                2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>:

                    +1

                    Phil


                     > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <mscurtescu@google.com

                    <mailto:mscurtescu@google.com>> wrote:
                     >
                     > There were a couple of proposals on how to
                    distinguish SETs from Id Tokens and Access Tokens in
                    such a way that naive implementations will not
                    confuse one for the other and open up security
                    vulnerabilities.
                     >
                     > There is also another important requirement: the
                    SET issuer in some cases must be different from the
                    "sub" issuer. This is the case of an RP sending SETs
                    to an IdP.
                     >
                     > With these requirements in mind I propose the
                    following:
                     > - both "sub" and "iss" to be defined at the event
                    level
                     > - "iss" at event level and at top SET level can
                    be different
                     > - "iss" and "sub" at event level can be different
                    across events in the same SET
                     > - "sub" should NOT be present at the top SET
                    level (this solves the disambiguation), please note
                    "should" and not "must"
                     >
                     > This solution also allows different profiles that
                    define event types to define additional claims
                    related to sub (like email or phone_number) and
                    since all these claims will be at the event level
                    there will be no collisions or ambiguity.
                     >
                     > Another proposal (which I supported) was to
                    define a composite "aud" claim. This is not solving
                    the requirement for a distinct  SET issuer. Also,
                    having the same claim name having different syntax
                    in different token types could lead to confusion.
                     >
                     > And yet another proposal was to introduce a new
                    claim for JWTs that defines a "type". This is not
                    practical in the short term, and it also is not
                    solving the distinct issuer requirement, but I think
                    this is something the JWT group should seriously
                    consider.
                     >
                     > Thoughts?
                     >
                     > Marius

                     > _______________________________________________
                     > Id-event mailing list

                     > Id-event@ietf.org <mailto:Id-event@ietf.org>
                     >
                    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=

                    _______________________________________________
                    Id-event mailing list
                    Id-event@ietf.org <mailto:Id-event@ietf.org>
                    https://www.ietf.org/mailman/listinfo/id-event

                _______________________________________________
                Id-event mailing list
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product Manager |adawes@google.com
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            _______________________________________________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--------------58DBD4A5830951D0890901F5-- From nobody Sat Jun 17 14:07:02 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DC0129BF7 for ; Sat, 17 Jun 2017 14:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vZ9nmAQOzvf for ; Sat, 17 Jun 2017 14:06:56 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0103.outbound.protection.outlook.com [104.47.41.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65E3129BF2 for ; Sat, 17 Jun 2017 14:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0PxX7CJ2qworfJA8shODizGREk2aQP7f1lkncX4E3uU=; b=JTDPXcHzwOy/4FcdukTCCQvCPAdbj+AGIWAjOzZC01gvAcseLaWkaNTOKFrAB/8tjpQghDK/4VJuwCA8DrfTSEX/n58f77xt1PIxbvwXYQ7PjWoifXVnPKY6+bQv0h6vmxtMYvn4onmZPlCI99EkMsF2zinCojMTOVGZVIbO7ZQ= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0502.namprd21.prod.outlook.com (10.172.122.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Sat, 17 Jun 2017 21:06:53 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1199.007; Sat, 17 Jun 2017 21:06:52 +0000 From: Mike Jones To: Yaron Sheffer , Justin Richer , Marius Scurtescu CC: "Richard Backman, Annabelle" , Henk Birkholz , ID Events Mailing List , Phil Hunt Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAAAQ5A= Date: Sat, 17 Jun 2017 21:06:52 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> In-Reply-To: <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-17T14:06:45.9544724-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0502; 7:qvKLx8YT4kiGeMnIOxF9qjGfgxxJ+ekRHL9TvjlIDUlSqJjx1eTX7AYhvt7k96MizVFHB2MwRtV+sGR/2FiEIBdETzGCEwNur+xCc9oDY08As3xzJw0zySe6UJFmAVSdo/HxrQv4uqT874AKI8nuZCGkT5AwHwXUkI8qmMhc1PoNmVjte/evCB14PBkJcHNr29uU3/l8sm0Kl/gZ9/KvWwWqfGxS5NwZIskNft7oozX7d09F13O2n9EdkmrF9QN18ZQkZJc+woqQyzJ7QDX1RFaR1jPuuZEdK07/UjjZF52iNVWhDuDqooYXSy0vzN+spj+caQwVpqxkVNy0ix8UtuOcUXXi+YO2XSk8+gY+g/idtiZ/QgT4iYRF+m2gzO2PaQQi3tDvq3GEsUKDgMoKqwl+A0BQZaPzr14kW8g0ttNs6123YlPfubzBd0IOWNP+wCI320VHKPl9/IR+Mh088Ic+oF6kCtkfOXkZMt24HS5zG/j8OYpabUgaT/mlB7Oh51bDynKo404X7r6X1Fz8vnjzBvY5YG7u8xqnowuZzjWtLXBfgYo5OHKGusAUZl78O3HyGdWU3ZzT7YA0dp82m03TS22GunABieheiJ2ZLmEefOt1rI2eNozMySpMKlNAaH2qnNvdiLm6xczRkixD5uxtbdde+ohxU2pTDmAZhmYnO2qG5SL0uRkdTbLhg9x/iAisx6R9Wmg3z3Oa/DmoJSyCDClD18P/AzORWfnncmriEnSL0N4gVvTtQfwAtIJAHtSRHOVRZjjTm1HS79iuRKGJIYEGIImvBIBOKtUXKuSSQQtvy1jJgQr6/qVnzxtY x-ms-office365-filtering-correlation-id: 2efd1b67-2544-4eb8-5de1-08d4b5c4c72c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:CY4PR21MB0502; x-ms-traffictypediagnostic: CY4PR21MB0502: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(131327999870524)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(47284530071512)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0502; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0502; x-forefront-prvs: 034119E4F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39410400002)(39400400002)(39850400002)(209900001)(24454002)(51914003)(377424004)(377454003)(77096006)(2171002)(54906002)(966005)(6246003)(6436002)(6506006)(53936002)(8990500004)(25786009)(53546009)(53946003)(575784001)(72206003)(86612001)(236005)(9686003)(10090500001)(55016002)(99286003)(6306002)(86362001)(54896002)(5660300001)(2906002)(39060400002)(38730400002)(4326008)(53376002)(33656002)(606005)(5005710100001)(3660700001)(3280700002)(122556002)(97736004)(189998001)(2950100002)(7696004)(7906003)(93886004)(76176999)(74316002)(50986999)(54356999)(3846002)(7736002)(81166006)(8936002)(8676002)(561944003)(14454004)(102836003)(790700001)(6116002)(66066001)(2900100001)(229853002)(68736007)(478600001)(10290500003)(579004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0502; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05044F0DB071245AE3D4C05EF5C60CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2017 21:06:52.4467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0502 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 21:07:01 -0000 --_000_CY4PR21MB05044F0DB071245AE3D4C05EF5C60CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gc29ycnkgdG8gYmUgc2xvdyByZXBseWluZyB0byBzb21lIG1lc3NhZ2VzIGluIHRoaXMg dGhyZWFkLiAgSSBoYXZlIGEgbG90IG9mIG90aGVyIHRoaW5ncyBvbiBteSBwbGF0ZSwgYnV0IEkg d2lsbCB0YWtlIHRoZSB0aW1lIG5vdyB0byByZXBseSwgYmVjYXVzZSBJIHdob2xlaGVhcnRlZGx5 IGRpc2FncmVlIHdpdGggc29tZSBvZiB0aGUgc3RhdGVtZW50cyBiZWxvdyBhbmQgYmVsaWV2ZSBp dCB3b3VsZCBiZSBzZXZlcmVseSBoYXJtZnVsIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGFuZCBpdHMg YWRvcHRpb24gdG8gYWN0IHVwb24gdGhlbS4gIFNwZWNpZmljYWxseToNCg0KDQogICogICBJIGRp c2FncmVlIHRoYXQgc3BlY2lmaWMgcnVsZXMgc2hvdWxkIGJlIG1hZGUgZm9yIHRoZSDigJxzdWLi gJ0gY2xhaW0uICBDbGFpbXMgdXNhZ2UgbmVlZHMgdG8gYmUgdXAgdG8gdGhlIGFwcGxpY2F0aW9u LiAgSSBrbm93IHRoYXQgbWFueSBvdGhlcnMgYWdyZWUgd2l0aCBtZSwgYmVjYXVzZSB0aGUgT3Bl bklEIENvbm5lY3Qgd29ya2luZyBncm91cCBkZXNpZ25lZCB0aGUgbG9nb3V0IHRva2VuIGluIGh0 dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJhY2tjaGFubmVsLTFfMC0wNC5o dG1sI0xvZ291dFRva2VuICh3aGljaCBpcyBhbHNvIHVzZWQgYXMgYW4gZXhhbXBsZSBpbiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0wMSNzZWN0 aW9uLTIpIHRvIHVzZSB0aGUg4oCcc3Vi4oCdIGNsYWltIGluIHRoZSBub3JtYWwgd2F5LiAgUHJv aGliaXRpbmcgdGhpcyB1c2FnZSB3b3VsZCBiZSBhIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgYnJl YWtpbmcgY2hhbmdlIOKAkyBhcyBpdOKAmXMgaW1wb3NzaWJsZSB0byBjb25mdXNlIGEgbG9nb3V0 IHRva2VuIHdpdGggYW4gSUQgVG9rZW4sIGZvciByZWFzb25zIGFscmVhZHkgY2l0ZXMgaW4gdGhp cyB0aHJlYWQuDQoNCg0KICAqICAgKEkgYWdyZWUgd2l0aCB0aGUg4oCcaXNz4oCdIHJ1bGVzIGFs cmVhZHkgaW4gcGxhY2UgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yLjEuICBObyBmdXJ0aGVyIOKAnGlzc+KAnSBydWxl cyBhcmUgbmVlZGVkLikNCg0KDQogICogICBJdOKAmXMgZmluZSBmb3IgdGhlIOKAnHR5cOKAnSBo ZWFkZXIgcGFyYW1ldGVyIHRvIGJlIHVzZWQgZm9yIHNvbWUgcHJvZmlsZXMgdG8gZGlmZmVyZW50 aWF0ZSBiZXR3ZWVuIGtpbmRzIG9mIEpXVHMuICBJdHMgdXNlIHNob3VsZCBub3QgYmUgbWFuZGF0 ZWQgaW4gdGhlIFNFVCBzcGVjLiAgSSB3b3VsZCBvcHBvc2UgZHVwbGljYXRpbmcgdGhlIOKAnHR5 cOKAnSBmdW5jdGlvbmFsaXR5IGJ5IGRlZmluaW5nIGFub3RoZXIgY2xhaW0gd2l0aCBhIGR1cGxp Y2F0aXZlIG1lYW5pbmcuDQoNCg0KICAqICAgSeKAmWxsIGFsc28gcmVzcG9uZCB0byBBbm5hYmVs bGXigJlzIGFzc2VydGlvbiB0aGF0IOKAnE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVy IHVzZSB0aGUgIm5vbmNl4oCdIGNsYWltLuKAnSAgVGhpcyByZWZsZWN0cyBhIG1pc3VuZGVyc3Rh bmRpbmcuICBJdOKAmXMgdGhlICp2YWx1ZSogb2YgdGhlIG5vbmNlIHRoYXQgc2VsZi1zZWN1cmVz IHRoZSBKV1Qg4oCTIG5vdCB0aGF0IGFueSDigJxub25jZeKAnSBjbGFpbSBpcyBwcmVzZW50LiAg QW55IGFuZCBhbGwgSldUcyBjYW4gc2ltdWx0YW5lb3VzbHkgdXNlIOKAnG5vbmNl4oCdIHdpdGhv dXQgYW55IHJpc2sgb2YgY29uZmxpY3QsIHNpbmNlIHRoZSBub25jZSB2YWx1ZSBpcyBhIGNyeXB0 b2dyYXBoaWNhbGx5IHNlY3VyZSByYW5kb20gbnVtYmVyLg0KDQpXaWxsIHNvbWUgb2YgeW91IGJl IGF0IHRoZSBDbG91ZCBJZGVudGl0eSBTdW1taXQgbmV4dCB3ZWVrPyAgSeKAmWQgYmUgZ2xhZCB0 byBoYXZlIGluLXBlcnNvbiBkaXNjdXNzaW9ucyBhYm91dCB0aGVzZSB0b3BpY3MgdGhlcmUuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNClAuUy4gIEZvb2QgZm9yIHRob3VnaHQ6ICBQcm9oaWJpdGluZyB0aGUgdXNlIG9m IOKAnHN1YuKAnSAob3IgYW55IG90aGVyIGNsYWltKSBvciBmb3JjaW5nIGl0IHRvIGJlIGxvY2F0 ZWQgaW4gYSBub24tc3RhbmRhcmQgbG9jYXRpb24gbWFrZXMgYWJvdXQgYXMgbXVjaCBzZW5zZSBh cyBhcmJpdHJhcmlseSBzYXlpbmcgdGhhdCwgZm9yIGEgcGFydGljdWxhciBwcm9maWxlLCB0aGUg TGF0aW4gd29yZCBmb3Igc3ViamVjdCDigJxzdWJpZWN0dW3igJ0gbXVzdCBiZSB1c2VkIGFzIHRo ZSBjbGFpbSBuYW1lIGluc3RlYWQgb2Yg4oCcc3Vi4oCdLiAgWWVzLCBpdCB3aWxsIGNvbXBsZXRl bHkgZGlmZmVyZW50aWF0ZSB0aGlzIHByb2ZpbGUgZnJvbSBvdGhlcnMgbm90IHNwZWxsaW5nIHRo ZSBjbGFpbSBuYW1lIHRoaXMgd2F5LCBidXQgaXQgd291bGQgY2VydGFpbmx5IGJlIGFuIGltcGVk aW1lbnQgdG8gdGhlIHVzZSBvZiBzdGFuZGFyZCBKV1QgbGlicmFyaWVzIGFuZCB0byBpbnRlcm9w ZXJhYmlsaXR5Lg0KDQpGcm9tOiBZYXJvbiBTaGVmZmVyIFttYWlsdG86eWFyb25mLmlldGZAZ21h aWwuY29tXQ0KU2VudDogU2F0dXJkYXksIEp1bmUgMTcsIDIwMTcgMTo0NSBQTQ0KVG86IEp1c3Rp biBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VA Z29vZ2xlLmNvbT4NCkNjOiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1h em9uLmNvbT47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IEhlbmsg Qmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+OyBJRCBFdmVudHMgTWFp bGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz47IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNs ZS5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRv a2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQoNClNvIHRvIHN1bW1hcml6 ZSB3aGF0IEknbSBzZWVpbmcgb24gdGhpcyB0aHJlYWQ6DQoNCkV2ZXJ5Ym9keSBhZ3JlZXMgd2l0 aCBNYXJpdXMncyBzaG9ydC10ZXJtIHNvbHV0aW9uLCBzcGVjaWZpYyBydWxlcyBmb3IgInN1YiIg YW5kICJpc3MiIHRoYXQgY2FuIGJlIGRlZmluZWQgaW4gdGhlIFNFVCBzcGVjLg0KDQpBbG1vc3Qg ZXZlcnlib2R5IGFncmVlcyBvbiBhIGxvbmctdGVybSAidXNhZ2UiIGNsYWltICgidHlwZSIgaXMg dGFrZW4pIHRoYXQgc2hvdWxkIGJlIGRlZmluZWQgZWxzZXdoZXJlLCBlLmcuIGluIHRoZSBKV1Qg QkNQLg0KDQpEaWQgSSBtaXNzIGFueXRoaW5nPw0KDQpCeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQg YSAidXNhZ2UiIGNsYWltLCB3ZSBuZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1l bnQgYmVmb3JlIGl0IGlzIHB1Ymxpc2hlZC4NCg0KVGhhbmtzLA0KDQogICAgWWFyb24NCg0KT24g MTUvMDYvMTcgMjI6MDgsIEp1c3RpbiBSaWNoZXIgd3JvdGU6DQorMSB0byB0aGlzIGFzIHdlbGwu DQoNCiDigJQgSnVzdGluDQoNCk9uIEp1biAxNSwgMjAxNywgYXQgMTowOSBQTSwgTWFyaXVzIFNj dXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20+PiB3cm90ZToNCg0KKzEgdG8gd2hhdCBBbm5hYmVsbGUgc2FpZC4NCg0KQWxzbywgTWlrZSB5 b3UgYXJlIG1pc3NpbmcgdGhlIG90aGVyIHJlcXVpcmVtZW50LCBmb3IgUlBzIHRvIHNlbmQgZXZl bnRzIHRvIGFuIElkUC4gVGhlIGlzcytzdWIgcGFpciBhdCB0aGUgdG9wIGxldmVsIGlzIGJyb2tl biBpbiB0aGlzIGNhc2UuDQoNCk1hcml1cw0KDQpPbiBXZWQsIEp1biAxNCwgMjAxNyBhdCA1OjMz IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KKzENCg0KUGhpbA0KDQpPbiBKdW4gMTQsIDIwMTcsIGF0 IDU6MjUgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29t PG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQpNaWtlLA0KDQpZb3VyIGV4cGxh bmF0aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1wcm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNp ZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVuSUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRl c2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFzIGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsIGlz c3VlcyB3aXRoIGl0Og0KDQoxLiAgICAgICBUaGUgY2FsbGVyIG9mIHRoZSBUb2tlbiBFbmRwb2lu dCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBjZXJ0YWluIHRoYXQgYSBub25jZS1sZXNz IElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tlbi4gQW55IHBhcnR5IHRoYXQgdGhlIGNhbGxl ciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBoYXMgbm8gd2F5IHRvIHZlcmlmeSBpdHMgcHJv dmVuYW5jZS4NCg0KMi4gICAgICAgQW55IGZ1dHVyZSBJRCBUb2tlbiBkaXN0cmlidXRpb24gbWV0 aG9kIG5lZWRzIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBhZ2Fpbi4NCg0KMy4gICAgICBObyBvdGhl ciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2UgdGhlICJub25jZeKAnSBjbGFpbS4NCg0KNC4g ICAgICBUaGlzIGlzIG9ubHkgYSBzb2x1dGlvbiBmb3IgSUQgVG9rZW5zLiBFdmVyeSBvdGhlciBK V1QgcHJvZmlsZSB0aGF0IGNhcmVzIGFib3V0IGRpc2FtYmlndWF0aW9uIGhhcyB0byBpbnZlbnQg aXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4NCg0KV2Uga25vdyBmcm9tIGV4cGVyaWVu Y2UgdGhhdCBuYW1pbmcgY29sbGlzaW9ucyBhbmQgcmVwbGF5IGF0dGFja3MgYXJlIGJvdGggdGhp bmdzIHRoYXQgaGFwcGVuLiBXaGF04oCZcyBiZWluZyBwcm9wb3NlZCBpcyBhIHNpbXBsZSwgZGVm ZW5zaXZlIG1lYXN1cmUgYWdhaW5zdCB0aGVzZSByaXNrcy4gWW91IGJyb3VnaHQgdXAgSldUIGxp YnJhcmllczogYSBnZW5lcmFsIHNvbHV0aW9uIGFjdHVhbGx5IG1ha2VzIGl0IGVhc2llciB0byB1 c2UgY29tbW9uIGxpYnJhcmllcyBmb3IgSldUIHBhcnNpbmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0g SldUIGxpYnJhcnkgY291bGQgaGFuZGxlIGRpc2FtYmlndWF0aW9uIGZvciBhbnkgSldUIHByb2Zp bGUsIHdoZXJlYXMgd2l0aCB0aGUgc3RhdHVzIHF1byBlYWNoIHByb2ZpbGUgd291bGQgcmVxdWly ZSB1bmlxdWUgbG9naWMuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0 eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyBhdCAxOjE2IFBNDQpU bzogTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20+Pg0KQ2M6ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hh bm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiwgSUQgRXZlbnRzIE1h aWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4s IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g c29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBp c3N1ZXINCg0KWW914oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4g IEnigJlkIGNoYXJhY3Rlcml6ZSB0aGUgcHJvcG9zYWxzIGluIHRoaXMgdGhyZWFkIGFzIOKAnHBy ZW1hdHVyZSBwZXNzaW1hdGlvbuKAnSDigJMgbWFraW5nIHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hv dWxkIGJlIHNpbXBsZSBjb21wbGV4LCB3aXRob3V0IGRhdGEgc2hvd2luZyB0aGVyZeKAmXMgYW55 IG5lZWQgdG8gZG8gc28uDQoNCk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2Vk IGluIHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRo YXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZlLiAgSXTigJlzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hl ZCB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZvciBhIFNFVCB0byBiZSBjb25mdXNlZCBmb3IgYW4g SUQgVG9rZW4g4oCTIHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lk LWV2ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJf aWQtMkRldmVudF9jdXJyZW50X21zZzAwNDI4Lmh0bWwmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6 Um9haTExNWMmcz1lS0xUUVBtWXJWM1RoZkRibjkwU0NzNTVVUk9UUGluX2xnYzZSZHI1WG93JmU9 Pi4gIElmIHBlb3BsZSBoYXZlIGRhdGEgc2hvd2luZyB0aGF0IHRoaXMgaXMgcG9zc2libGUgd2l0 aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9rZW5zIG9yIG90aGVyIHJlYWwgSldUIGRlcGxv eW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZpY3MsIHNvIHRoYXQgd2UgY2FuIHVzZSB0aGF0 IGRhdGEgdG8gaW5mb3JtIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNob2ljZXMgb24gb3VyIHBh cnQuDQoNClRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPigJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcg dGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1hbCB3YXksIG9yIHJlcXVpcmluZyBhIHR5 cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNseSBzaW1wbGUgdGhpbmdzIHVubmVjZXNzYXJp bHkgY29tcGxleC4gIFllcywgdGhlbiB0aGUgcmVzdWx0IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4g YSBub3JtYWwgSldUIGJ1dCBhIGNvbnNlcXVlbmNlIG9mIHRoaXMgaXMgdGhhdCBjdXN0b20gcGFy c2luZyBjb2RlIHdvdWxkIGhhdmUgdG8gYmUgdXNlZCwgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBK V1QgcGFyc2VyLiAgVGhlIG1vcmUgdW53aWVsZHkgd2UgbWFrZSBpdCB0byB1c2UgU0VUcywgdGhl IG1vcmUgbGlrZWx5IGRldmVsb3BlcnMgYXJlIHRvIGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRh IHN0cnVjdHVyZXMuICBLZWVwaW5nIGl0IHNpbXBsZSBpcyB0aGUga2V5IHRvIGFkb3B0aW9uLiAg U3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0aGV5IGFyZSBhY3R1YWxseSB1c2VkLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEz LCAyMDE3IDU6MzMgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5j b208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJp cmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRp b24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXIN Cg0KRWNob2luZyBNYXJpdXPigJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3Ug bWVhbiBieSDigJxpbnRlbmTigJ0/DQoNClRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsg YSBiZXR0ZXIgYW5hbG9neSB3b3VsZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjog YSBtdWx0aS12YWx1ZWQgcHJvcGVydHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9z ZSBvZiB0aGUgSldULCBhbmQgdGhhdCBhIHJlY2lwaWVudCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRl cm1pbmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpXVCBiZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4g c29tZSBjb250ZXh0Lg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkg U2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1 cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bT4+DQpEYXRlOiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IGF0IDExOjA1IEFNDQpUbzogSGVuayBC aXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpDYzogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb SWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0 aW5jdCBTRVQgaXNzdWVyDQoNCk9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsg Qmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmly a2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+PiB3cm90ZToNCkFuZCBhIDJuZCBxdWVzdGlvbi4NCg0K V2hhdCBzZW1hbnRpY3Mgd291bGQgInVzYWdlIiBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNv dmVyZWQgdmlhICJpbnRlbmQiLCAiYXVkaWVuY2UiLCBhbmQgInNjb3BlIj8NCg0KImF1ZCIgKGF1 ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdldCBjbGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVk IHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0aG9yaXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQg dG8gY29tbXVuaWNhdGUgYSBzZWN1cml0eSBldmVudD8pDQoNCiJzY29wZSIgaXMgbm90IHVzZWQg YnkgU0VULg0KDQpJIGRvbid0IGtub3cgd2hhdCBkbyB5b3UgbWVhbiBieSAiaW50ZW5kIiAob3Ig aW50ZW50KT8NCg0KDQoNCg0KSGVuaw0KDQpPbiAwNi8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSB3cm90ZToNClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0 aGVyIQ0KDQpJIHRoaW5rIHRoZSBhc3N1bXB0aW9ucyBpbmhlcmVudCBpbiAzLjkgYXJlIGZsYXdl ZDoNCg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwg aGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFk ZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBh biB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9t IHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0YWtlbiBmb3IgSldUcyBmcm9tIGEgY3Vy cmVudCBzcGVjLg0KDQrCt0l0IGlzIHVucmVhbGlzdGljIHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMg dG8gYWRoZXJlIHRvIHRoZSDigJxkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9m IEpXVHPigJ0gcnVsZS4gV2hldGhlciBtYW5kYXRlZCBieSB0aGUgc3BlYyBvciBub3QsIGltcGxl bWVudGVycyB3aWxsIGlnbm9yZSB0aGlzIGJlY2F1c2UgbWFuYWdpbmcgb25lIGtleSBpcyBlYXNp ZXIgdGhhbiBtYW5hZ2luZyBOIGRpZmZlcmVudCBrZXlzLg0KDQrCt0RpdHRvIGZvciDigJxhdWTi gJ0gYW5kIOKAnGlzc+KAnSBjbGFpbXMuDQoNCisxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNh Z2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci4NCg0KLS0NCg0KQW5uYWJlbGxlIFJpY2hhcmQg QmFja21hbg0KDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoqRnJvbTogKklkLWV2ZW50IDxpZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbT4+DQoqRGF0ZTogKk1vbmRheSwgSnVuZSAxMiwgMjAxNyBhdCAzOjE4IFBN DQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbT4+DQoqQ2M6ICpBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNv bTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+PiwgIm1hdGFrZSwgbm92IiA8bm92QG1hdGFrZS5q cDxtYWlsdG86bm92QG1hdGFrZS5qcD4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgIlBoaWwgSHVudCAoSURNKSIg PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoqU3Vi amVjdDogKlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVz aW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlz IHN0aWxsIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB3aGF0IHNob3VsZCBiZSBpbiAzLjkuDQoNCk9u IE1vbiwgSnVuIDEyLCAyMDE3IGF0IDM6MTUgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVz Y3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPiA8bWFpbHRvOm1zY3Vy dGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4+IHdyb3RlOg0K DQogICAgVGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2ZXJ5IGdvb2QgdGltaW5nIDotKQ0K DQogICAgVGhlIGlzc3VlIGlzIGRlc2NyaWJlZCBieSAiMi43LiBDcm9zcy1KV1QgQ29uZnVzaW9u IiBhbmQgdGhlDQogICAgbWl0aWdhdGlvbiBpcyBpbiAiMy45LiBVc2UgTXV0dWFsbHkgRXhjbHVz aXZlIFZhbGlkYXRpb24gUnVsZXMgZm9yDQogICAgRGlmZmVyZW50IEtpbmRzIG9mIEpXVHMiLCBz cGVjaWZpY2FsbHkgIlVzZSBkaWZmZXJlbnQgc2V0cyBvZg0KICAgIHJlcXVpcmVkIGNsYWltcy4u LiIsICJVc2UgZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZg0KICAgIEpXVHMu IiBhbmQgIlVzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMu Ii4NCg0KICAgIEkgc3RpbGwgdGhpbmsgdGhhdCBhICJ0eXBlIiBjbGFpbSB3b3VsZCBicmluZyBh IGxvdCBvZiBjbGFyaXR5IGFuZA0KICAgIHNhZmV0eS4NCg0KDQogICAgTWFyaXVzDQoNCiAgICBP biBUaHUsIEp1biA4LCAyMDE3IGF0IDk6NTkgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21h aWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCiAgICA8bWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+PiB3cm90ZToNCg0KICAg ICAgICBZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVA0K ICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkwPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zZWxmLTJEaXNzdWVkLmluZm9fLTNG cC0zRDE2OTAmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVz bGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1hN1h2WjVqVGJ0QTJ2 amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmU9Pg0KDQogICAgICAgIE9uIFRodSwgSnVu IDgsIDIwMTcgYXQgOTowMiBQTSBBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86 YWRhd2VzQGdvb2dsZS5jb20+DQogICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb208bWFp bHRvOmFkYXdlc0Bnb29nbGUuY29tPj4+IHdyb3RlOg0KDQogICAgICAgICAgICBJIHdhcyBpbml0 aWFsbHkgYSBmYW4gb2Yga2VlcGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bw0KICAgICAg ICAgICAgaWQgdG9rZW5zIGJ1dCBJIG5vdyB0aGluayB0aGlzIGlzIGEgYmV0dGVyIHBsYW4uDQoN CiAgICAgICAgICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBtYXRha2UsIG5vdiA8 bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4NCiAgICAgICAgICAgIDxtYWlsdG86 bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4+PiB3cm90ZToNCg0KICAgICAgICAg ICAgICAgICsxIGVzcGVjaWFsbHkgZm9yICJ0eXBlIg0KDQogICAgICAgICAgICAgICAgMjAxNy0w Ni0wOSAxMDozMiBHTVQrMDk6MDAgUGhpbCBIdW50IChJRE0pDQogICAgICAgICAgICAgICAgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4gPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pj46DQoNCiAg ICAgICAgICAgICAgICAgICAgKzENCg0KICAgICAgICAgICAgICAgICAgICBQaGlsDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgPiBPbiBKdW4gOCwgMjAxNywgYXQgNjoyOCBQTSwgTWFyaXVzIFNj dXJ0ZXNjdQ0KICAgICAgICAgICAgICAgICAgICA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0 bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+DQogICAgICAgICAgICAgICAgICAgIDxtYWlsdG86bXNj dXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6 DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoZXJlIHdl cmUgYSBjb3VwbGUgb2YgcHJvcG9zYWxzIG9uIGhvdyB0bw0KICAgICAgICAgICAgICAgICAgICBk aXN0aW5ndWlzaCBTRVRzIGZyb20gSWQgVG9rZW5zIGFuZCBBY2Nlc3MgVG9rZW5zIGluDQogICAg ICAgICAgICAgICAgICAgIHN1Y2ggYSB3YXkgdGhhdCBuYWl2ZSBpbXBsZW1lbnRhdGlvbnMgd2ls bCBub3QNCiAgICAgICAgICAgICAgICAgICAgY29uZnVzZSBvbmUgZm9yIHRoZSBvdGhlciBhbmQg b3BlbiB1cCBzZWN1cml0eQ0KICAgICAgICAgICAgICAgICAgICB2dWxuZXJhYmlsaXRpZXMuDQog ICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoZXJlIGlzIGFs c28gYW5vdGhlciBpbXBvcnRhbnQgcmVxdWlyZW1lbnQ6IHRoZQ0KICAgICAgICAgICAgICAgICAg ICBTRVQgaXNzdWVyIGluIHNvbWUgY2FzZXMgbXVzdCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUNCiAg ICAgICAgICAgICAgICAgICAgInN1YiIgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQ IHNlbmRpbmcgU0VUcw0KICAgICAgICAgICAgICAgICAgICB0byBhbiBJZFAuDQogICAgICAgICAg ICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFdpdGggdGhlc2UgcmVxdWlyZW1l bnRzIGluIG1pbmQgSSBwcm9wb3NlIHRoZQ0KICAgICAgICAgICAgICAgICAgICBmb2xsb3dpbmc6 DQogICAgICAgICAgICAgICAgICAgICA+IC0gYm90aCAic3ViIiBhbmQgImlzcyIgdG8gYmUgZGVm aW5lZCBhdCB0aGUgZXZlbnQNCiAgICAgICAgICAgICAgICAgICAgbGV2ZWwNCiAgICAgICAgICAg ICAgICAgICAgID4gLSAiaXNzIiBhdCBldmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBsZXZlbCBj YW4NCiAgICAgICAgICAgICAgICAgICAgYmUgZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAg ICA+IC0gImlzcyIgYW5kICJzdWIiIGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQNCiAg ICAgICAgICAgICAgICAgICAgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQNCiAgICAgICAg ICAgICAgICAgICAgID4gLSAic3ViIiBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBT RVQNCiAgICAgICAgICAgICAgICAgICAgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3Vh dGlvbiksIHBsZWFzZSBub3RlDQogICAgICAgICAgICAgICAgICAgICJzaG91bGQiIGFuZCBub3Qg Im11c3QiDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRo aXMgc29sdXRpb24gYWxzbyBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQNCiAgICAgICAg ICAgICAgICAgICAgZGVmaW5lIGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWlt cw0KICAgICAgICAgICAgICAgICAgICByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9u ZV9udW1iZXIpIGFuZA0KICAgICAgICAgICAgICAgICAgICBzaW5jZSBhbGwgdGhlc2UgY2xhaW1z IHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxldmVsDQogICAgICAgICAgICAgICAgICAgIHRoZXJlIHdp bGwgYmUgbm8gY29sbGlzaW9ucyBvciBhbWJpZ3VpdHkuDQogICAgICAgICAgICAgICAgICAgICA+ DQogICAgICAgICAgICAgICAgICAgICA+IEFub3RoZXIgcHJvcG9zYWwgKHdoaWNoIEkgc3VwcG9y dGVkKSB3YXMgdG8NCiAgICAgICAgICAgICAgICAgICAgZGVmaW5lIGEgY29tcG9zaXRlICJhdWQi IGNsYWltLiBUaGlzIGlzIG5vdCBzb2x2aW5nDQogICAgICAgICAgICAgICAgICAgIHRoZSByZXF1 aXJlbWVudCBmb3IgYSBkaXN0aW5jdCAgU0VUIGlzc3Vlci4gQWxzbywNCiAgICAgICAgICAgICAg ICAgICAgaGF2aW5nIHRoZSBzYW1lIGNsYWltIG5hbWUgaGF2aW5nIGRpZmZlcmVudCBzeW50YXgN CiAgICAgICAgICAgICAgICAgICAgaW4gZGlmZmVyZW50IHRva2VuIHR5cGVzIGNvdWxkIGxlYWQg dG8gY29uZnVzaW9uLg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAg ICAgPiBBbmQgeWV0IGFub3RoZXIgcHJvcG9zYWwgd2FzIHRvIGludHJvZHVjZSBhIG5ldw0KICAg ICAgICAgICAgICAgICAgICBjbGFpbSBmb3IgSldUcyB0aGF0IGRlZmluZXMgYSAidHlwZSIuIFRo aXMgaXMgbm90DQogICAgICAgICAgICAgICAgICAgIHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVy bSwgYW5kIGl0IGFsc28gaXMgbm90DQogICAgICAgICAgICAgICAgICAgIHNvbHZpbmcgdGhlIGRp c3RpbmN0IGlzc3VlciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbmsNCiAgICAgICAgICAgICAgICAg ICAgdGhpcyBpcyBzb21ldGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5DQogICAg ICAgICAgICAgICAgICAgIGNvbnNpZGVyLg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAg ICAgICAgICAgICAgICAgPiBUaG91Z2h0cz8NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAg ICAgICAgICAgICAgICAgID4gTWFyaXVzDQoNCiAgICAgICAgICAgICAgICAgICAgID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAg ICAgICAgID4gSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgICAgICA+IElk LWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAg ICAgPg0KICAgICAgICAgICAgICAgICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJE ZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPUptdXV0 Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmcz01eFFxdkJpWFo2SWo5TkdE d1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmU9DQoNCiAgICAgICAgICAgICAgICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAg ICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgICAgIElkLWV2 ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAg ICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgICAgICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAg ICAgIElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJv YWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4N Cg0KICAgICAgICAgICAgLS0NCiAgICAgICAgICAgIEFkYW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBN YW5hZ2VyIHxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+DQogICAg ICAgICAgICA8bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bT4+IHwrMSA2NTAtMjE0LTI0MTA8dGVsOiUyQjElMjA2NTAtMjE0LTI0MTA+DQogICAgICAgICAg ICA8dGVsOig2NTApJTIwMjE0LTI0MTA8dGVsOiUyODY1MCUyOSUyMDIxNC0yNDEwPj4NCg0KICAg ICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgSWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRw a0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdr Jm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pz c0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgLS0NCiAg ICAgICAgU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLzxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3 YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVz bGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1pNzVVdzhhZWhZdmxw SVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFpbCBsaXN0IHRvDQogICAgICAg IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQoNClN1YnNj cmliZSB0byB0aGUgSEFSRFRXQVJFIDxodHRwOi8vaGFyZHR3YXJlLmNvbS88aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9 RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hz aG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9aTc1VXc4YWVoWXZscElaTkw3TnhxR3ho aDFUT3JRT1VYMlhNWUJlclY4MCZlPT4+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0 cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZk PUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtI c2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0 RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZy PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQ S0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdM RDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0 Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNz S0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJ ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KSWQtZXZlbnQgbWFpbGluZyBs aXN0DQoNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQo= --_000_CY4PR21MB05044F0DB071245AE3D4C05EF5C60CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAubTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdy YXBoLCBsaS5tOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tOTA5NDA4 OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV85MDk0MDg5 MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAyMDgxNjc5ODsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI0NTYxOTE4MiA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J4oCZbSBzb3JyeSB0byBi ZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUgbWVzc2FnZXMgaW4gdGhpcyB0aHJlYWQuJm5ic3A7IEkg aGF2ZSBhIGxvdCBvZiBvdGhlciB0aGluZ3Mgb24gbXkgcGxhdGUsIGJ1dCBJIHdpbGwgdGFrZSB0 aGUgdGltZSBub3cgdG8gcmVwbHksIGJlY2F1c2UgSSB3aG9sZWhlYXJ0ZWRseSBkaXNhZ3JlZSB3 aXRoIHNvbWUgb2YgdGhlIHN0YXRlbWVudHMgYmVsb3cNCiBhbmQgYmVsaWV2ZSBpdCB3b3VsZCBi ZSBzZXZlcmVseSBoYXJtZnVsIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGFuZCBpdHMgYWRvcHRpb24g dG8gYWN0IHVwb24gdGhlbS4mbmJzcDsgU3BlY2lmaWNhbGx5OjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOiMwMDIw NjA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkkgZGlzYWdyZWUg dGhhdCBzcGVjaWZpYyBydWxlcyBzaG91bGQgYmUgbWFkZSBmb3IgdGhlIOKAnHN1YuKAnSBjbGFp bS4gJm5ic3A7Q2xhaW1zIHVzYWdlIG5lZWRzIHRvIGJlIHVwIHRvIHRoZSBhcHBsaWNhdGlvbi4m bmJzcDsgSSBrbm93IHRoYXQgbWFueSBvdGhlcnMgYWdyZWUgd2l0aCBtZSwgYmVjYXVzZSB0aGUg T3BlbklEIENvbm5lY3Qgd29ya2luZyBncm91cCBkZXNpZ25lZCB0aGUgbG9nb3V0IHRva2VuIGlu DQo8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1iYWNrY2hh bm5lbC0xXzAtMDQuaHRtbCNMb2dvdXRUb2tlbiI+DQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9v cGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAtMDQuaHRtbCNMb2dvdXRUb2tlbjwvYT4gKHdo aWNoIGlzIGFsc28gdXNlZCBhcyBhbiBleGFtcGxlIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0wMSNzZWN0aW9uLTIiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3Nl Y3Rpb24tMjwvYT4pIHRvIHVzZSB0aGUg4oCcc3Vi4oCdIGNsYWltIGluIHRoZSBub3JtYWwgd2F5 LiZuYnNwOyBQcm9oaWJpdGluZyB0aGlzIHVzYWdlIHdvdWxkIGJlIGEgY29tcGxldGVseSB1bm5l Y2Vzc2FyeSBicmVha2luZw0KIGNoYW5nZSDigJMgYXMgaXTigJlzIGltcG9zc2libGUgdG8gY29u ZnVzZSBhIGxvZ291dCB0b2tlbiB3aXRoIGFuIElEIFRva2VuLCBmb3IgcmVhc29ucyBhbHJlYWR5 IGNpdGVzIGluIHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KKEkgYWdyZWUgd2l0aCB0aGUg4oCcaXNz4oCd IHJ1bGVzIGFscmVhZHkgaW4gcGxhY2UgYXQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yLjEiPg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlv bi0yLjE8L2E+LiZuYnNwOyBObyBmdXJ0aGVyIOKAnGlzc+KAnSBydWxlcyBhcmUgbmVlZGVkLik8 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCkl04oCZcyBmaW5lIGZvciB0aGUg4oCcdHlw4oCdIGhlYWRlciBwYXJhbWV0ZXIgdG8g YmUgdXNlZCBmb3Igc29tZSBwcm9maWxlcyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4ga2luZHMg b2YgSldUcy4mbmJzcDsgSXRzIHVzZSBzaG91bGQgbm90IGJlIG1hbmRhdGVkIGluIHRoZSBTRVQg c3BlYy4mbmJzcDsgSSB3b3VsZCBvcHBvc2UgZHVwbGljYXRpbmcgdGhlIOKAnHR5cOKAnSBmdW5j dGlvbmFsaXR5IGJ5IGRlZmluaW5nIGFub3RoZXIgY2xhaW0gd2l0aCBhIGR1cGxpY2F0aXZlIG1l YW5pbmcuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQpJ4oCZbGwgYWxzbyByZXNwb25kIHRvIEFubmFiZWxsZeKAmXMgYXNzZXJ0 aW9uIHRoYXQg4oCcPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5ObyBvdGhlciBwcm9maWxlIG9m IEpXVCBjYW4gZXZlciB1c2UgdGhlICZxdW90O25vbmNl4oCdIGNsYWltLjwvc3Bhbj7igJ0mbmJz cDsgVGhpcyByZWZsZWN0cyBhIG1pc3VuZGVyc3RhbmRpbmcuJm5ic3A7IEl04oCZcyB0aGUgKjxi PnZhbHVlPC9iPiogb2YgdGhlIG5vbmNlIHRoYXQgc2VsZi1zZWN1cmVzIHRoZSBKV1Qg4oCTIG5v dCB0aGF0IGFueSDigJxub25jZeKAnQ0KIGNsYWltIGlzIHByZXNlbnQuJm5ic3A7IEFueSBhbmQg YWxsIEpXVHMgY2FuIHNpbXVsdGFuZW91c2x5IHVzZSDigJxub25jZeKAnSB3aXRob3V0IGFueSBy aXNrIG9mIGNvbmZsaWN0LCBzaW5jZSB0aGUgbm9uY2UgdmFsdWUgaXMgYSBjcnlwdG9ncmFwaGlj YWxseSBzZWN1cmUgcmFuZG9tIG51bWJlci48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+V2lsbCBzb21lIG9mIHlvdSBiZSBhdCB0aGUgQ2xvdWQgSWRlbnRpdHkgU3VtbWl0IG5l eHQgd2Vlaz8mbmJzcDsgSeKAmWQgYmUgZ2xhZCB0byBoYXZlIGluLXBlcnNvbiBkaXNjdXNzaW9u cyBhYm91dCB0aGVzZSB0b3BpY3MgdGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UC5TLiZuYnNwOyBGb29kIGZvciB0 aG91Z2h0OiZuYnNwOyBQcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSAob3IgYW55IG90 aGVyIGNsYWltKSBvciBmb3JjaW5nIGl0IHRvIGJlIGxvY2F0ZWQgaW4gYSBub24tc3RhbmRhcmQg bG9jYXRpb24gbWFrZXMgYWJvdXQgYXMgbXVjaCBzZW5zZSBhcyBhcmJpdHJhcmlseSBzYXlpbmcg dGhhdCwgZm9yIGEgcGFydGljdWxhciBwcm9maWxlLA0KIHRoZSBMYXRpbiB3b3JkIGZvciBzdWJq ZWN0IOKAnHN1YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5hbWUgaW5zdGVh ZCBvZiDigJxzdWLigJ0uJm5ic3A7IFllcywgaXQgd2lsbCBjb21wbGV0ZWx5IGRpZmZlcmVudGlh dGUgdGhpcyBwcm9maWxlIGZyb20gb3RoZXJzIG5vdCBzcGVsbGluZyB0aGUgY2xhaW0gbmFtZSB0 aGlzIHdheSwgYnV0IGl0IHdvdWxkIGNlcnRhaW5seSBiZSBhbiBpbXBlZGltZW50IHRvIHRoZSB1 c2Ugb2Ygc3RhbmRhcmQgSldUDQogbGlicmFyaWVzIGFuZCB0byBpbnRlcm9wZXJhYmlsaXR5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9z ZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBZYXJvbiBTaGVmZmVyIFttYWlsdG86 eWFyb25mLmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdW5l IDE3LCAyMDE3IDE6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNo ZXJAbWl0LmVkdSZndDs7IE1hcml1cyBTY3VydGVzY3UgJmx0O21zY3VydGVzY3VAZ29vZ2xlLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNo YW5uYUBhbWF6b24uY29tJmd0OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tJmd0OzsgSGVuayBCaXJraG9seiAmbHQ7aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZSZndDs7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0 OzsgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNp b24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5T byB0byBzdW1tYXJpemUgd2hhdCBJJ20gc2VlaW5nIG9uIHRoaXMgdGhyZWFkOjxvOnA+PC9vOnA+ PC9wPg0KPHA+RXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRp b24sIHNwZWNpZmljIHJ1bGVzIGZvciAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90 OyB0aGF0IGNhbiBiZSBkZWZpbmVkIGluIHRoZSBTRVQgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjxw PkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICZxdW90O3VzYWdlJnF1b3Q7 IGNsYWltICgmcXVvdDt0eXBlJnF1b3Q7IGlzIHRha2VuKSB0aGF0IHNob3VsZCBiZSBkZWZpbmVk IGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJDUC48bzpwPjwvbzpwPjwvcD4NCjxwPkRpZCBJ IG1pc3MgYW55dGhpbmc/PG86cD48L286cD48L3A+DQo8cD5CeSB0aGUgd2F5LCBpZiB3ZSBkbyBh ZGQgYSAmcXVvdDt1c2FnZSZxdW90OyBjbGFpbSwgd2UgbmVlZCB0byBhbHNvIHVzZSBpdCBpbiB0 aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8 cD5UaGFua3MsPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmlj aGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiYjNDM7MSB0byB0aGlzIGFzIHdlbGwuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBN LCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byB3aGF0IEFubmFiZWxsZSBz YWlkLiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28s IE1pa2UgeW91IGFyZSBtaXNzaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudCwgZm9yIFJQcyB0byBz ZW5kIGV2ZW50cyB0byBhbiBJZFAuIFRoZSBpc3MmIzQzO3N1YiBwYWlyIGF0IHRoZSB0b3AgbGV2 ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcml1czxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVuIDE0LCAy MDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fOTA5NDA4 OTIzOTY2ODU3MDMxMkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q aGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVuIDE0 LCAyMDE3LCBhdCA1OjI1IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBh bWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pa2UsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Zb3VyIGV4cGxhbmF0aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1wcm9ibGVtIGlz IGRlcGVuZGVudCB1cG9uIHNpZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVuSUQgQ29ubmVj dCB0aGF0IHdlcmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFzIGEgcmVzdWx0 LCBJIHNlZSBzZXZlcmFsDQogaXNzdWVzIHdpdGggaXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj4xLjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5UaGUgY2Fs bGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBj ZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tlbi4g QW55IHBhcnR5IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBoYXMg bm8gd2F5IHRvIHZlcmlmeSBpdHMgcHJvdmVuYW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiPjIuPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPkFueSBmdXR1 cmUgSUQgVG9rZW4gZGlzdHJpYnV0aW9uIG1ldGhvZCBuZWVkcyB0byBzb2x2ZSB0aGlzIHByb2Js ZW0gYWdhaW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTkwOTQwODkyMzk2Njg1NzAzMTJt c29saXN0cGFyYWdyYXBoIj4zLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj5ObyBvdGhlciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2Ug dGhlICZxdW90O25vbmNl4oCdIGNsYWltLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05MDk0 MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCI+NC48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+VGhpcyBpcyBvbmx5IGEgc29sdXRp b24gZm9yIElEIFRva2Vucy4gRXZlcnkgb3RoZXIgSldUIHByb2ZpbGUgdGhhdCBjYXJlcyBhYm91 dCBkaXNhbWJpZ3VhdGlvbiBoYXMgdG8gaW52ZW50IGl0cyBvd24gc29sdXRpb24gdG8gdGhlIHBy b2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBrbm93IGZyb20gZXhwZXJpZW5j ZSB0aGF0IG5hbWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGlu Z3MgdGhhdCBoYXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZl bnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3UgYnJvdWdodA0KIHVwIEpXVCBs aWJyYXJpZXM6IGEgZ2VuZXJhbCBzb2x1dGlvbiBhY3R1YWxseSBtYWtlcyBpdCBlYXNpZXIgdG8g dXNlIGNvbW1vbiBsaWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBBIOKAnHVzYWdlLWF3YXJl4oCd IEpXVCBsaWJyYXJ5IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlvbiBmb3IgYW55IEpXVCBwcm9m aWxlLCB3aGVyZWFzIHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBwcm9maWxlIHdvdWxkIHJlcXVp cmUgdW5pcXVlIGxvZ2ljLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWRlbnRp dHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPkZyb206DQo8L2I+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5l IDE0LCAyMDE3IGF0IDE6MTYgUE08YnI+DQo8Yj5UbzogPC9iPk1hcml1cyBTY3VydGVzY3UgJmx0 OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5t c2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7UmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBJ RCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7LCBIZW5rIEJpcmto b2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIg dGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNz IFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+WW914oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4mbmJz cDsgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCc cHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBz aG91bGQNCiBiZSBzaW1wbGUgY29tcGxleCwgd2l0aG91dCBkYXRhIHNob3dpbmcgdGhlcmXigJlz IGFueSBuZWVkIHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGluIHRoaXMgdGhyZWFk IHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0dWFsbHkg ZXZlbiBoYXZlLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkDQogdGhhdCBp dOKAmXMgaW1wb3NzaWJsZSBmb3IgYSBTRVQgdG8gYmUgY29uZnVzZWQgZm9yIGFuIElEIFRva2Vu IOKAkyBzZWUgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRf Y3VycmVudF9tc2cwMDQyOC5odG1sJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4 UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZhbXA7cz1lS0xUUVBtWXJWM1RoZkRibjkwU0NzNTVVUk9UUGluX2xnYzZS ZHI1WG93JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4Lmh0bWw8L2E+LiZuYnNwOyBJ ZiBwZW9wbGUgaGF2ZSBkYXRhIHNob3dpbmcgdGhhdCB0aGlzIGlzIHBvc3NpYmxlIHdpdGggc3Bl Y2lmaWMga2luZHMgb2YgQWNjZXNzIFRva2VucyBvciBvdGhlciByZWFsIEpXVCBkZXBsb3ltZW50 cywgcGxlYXNlIHByb3ZpZGUgc3BlY2lmaWNzLCBzbyB0aGF0IHdlIGNhbiB1c2UgdGhhdCBkYXRh IHRvIGluZm9ybQ0KIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNob2ljZXMgb24gb3VyIHBhcnQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlIHByb3Bvc2VkIOKA nHNvbHV0aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBp biB0aGUgbm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBw cmV2aW91c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseQ0KIGNvbXBsZXguJm5ic3A7IFll cywgdGhlbiB0aGUgcmVzdWx0IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1 dCBhIGNvbnNlcXVlbmNlIG9mIHRoaXMgaXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxk IGhhdmUgdG8gYmUgdXNlZCwgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiZuYnNw OyBUaGUgbW9yZSB1bndpZWxkeSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtl bHkgZGV2ZWxvcGVycyBhcmUgdG8NCiBqdXN0IGNyZWF0ZSB0aGVpciBvd24gZGF0YSBzdHJ1Y3R1 cmVzLiZuYnNwOyBLZWVwaW5nIGl0IHNpbXBsZSBpcyB0aGUga2V5IHRvIGFkb3B0aW9uLiZuYnNw OyBTdGFuZGFyZHMgYXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gSWQtZXZlbnQg WzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5SaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcml1cyBTY3VydGVzY3Ug Jmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OzsgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5r Ij5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBj b25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5FY2hvaW5nIE1hcml1c+KAmXMgcXVlc3Rpb246IGNhbiB5b3Ug ZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9n eSB3b3VsZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQg cHJvcGVydHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBh bmQgdGhhdCBhIHJlY2lwaWVudA0KIG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRo ZXIgdG8gYWNjZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbToN CjwvYj5JZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1 QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKdW5lIDEzLCAyMDE3IGF0IDExOjA1IEFNPGJy Pg0KPGI+VG86IDwvYj5IZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SUQgRXZlbnRzIE1haWxpbmcg TGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lk LWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGlu Y3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEp1biAxMywgMjAxNyBhdCAyOjEx IEFNLCBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9m ZXIuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQg YSAybmQgcXVlc3Rpb24uPGJyPg0KPGJyPg0KV2hhdCBzZW1hbnRpY3Mgd291bGQgJnF1b3Q7dXNh Z2UmcXVvdDsgcHJvdmlkZSB0aGF0IHRoYXQgYXJlIG5vdCBjb3ZlcmVkIHZpYSAmcXVvdDtpbnRl bmQmcXVvdDssICZxdW90O2F1ZGllbmNlJnF1b3Q7LCBhbmQgJnF1b3Q7c2NvcGUmcXVvdDs/PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+JnF1b3Q7YXVkJnF1b3Q7IChhdWRpZW5jZSkgc3BlY2lmaWVzIHRoZSB0YXJnZXQgY2xp ZW50LCBidXQgbm90IHRoZSBpbnRlbmRlZCB1c2FnZSAoYWNjZXNzIHRva2VuIHRvIGF1dGhvcml6 ZSByZXNvdXJjZSBhY2Nlc3Mgb3IgU0VUIHRvIGNvbW11bmljYXRlIGEgc2VjdXJpdHkgZXZlbnQ/ KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+JnF1b3Q7c2NvcGUmcXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb24ndCBrbm93IHdo YXQgZG8geW91IG1lYW4gYnkgJnF1b3Q7aW50ZW5kJnF1b3Q7IChvciBpbnRlbnQpPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnI+DQpIZW5r PGJyPg0KPGJyPg0KT24gMDYvMTMvMjAxNyAwMTowMSBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciBw dXR0aW5nIHRoaXMgdG9nZXRoZXIhPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgYXNzdW1wdGlvbnMg aW5oZXJlbnQgaW4gMy45IGFyZSBmbGF3ZWQ6PGJyPg0KPGJyPg0KwrdXZSBjYW7igJl0IGd1YXJh bnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2 ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5kIGVuZm9y Y2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xhaW3igJ0g YXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZ dCBiZSBtaXN0YWtlbiBmb3IgSldUcw0KIGZyb20gYSBjdXJyZW50IHNwZWMuPGJyPg0KPGJyPg0K wrdJdCBpcyB1bnJlYWxpc3RpYyB0byBleHBlY3QgaW1wbGVtZW50ZXJzIHRvIGFkaGVyZSB0byB0 aGUg4oCcZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1Rz4oCdIHJ1bGUu IFdoZXRoZXIgbWFuZGF0ZWQgYnkgdGhlIHNwZWMgb3Igbm90LCBpbXBsZW1lbnRlcnMgd2lsbCBp Z25vcmUgdGhpcyBiZWNhdXNlIG1hbmFnaW5nIG9uZSBrZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdp bmcgTiBkaWZmZXJlbnQga2V5cy48YnI+DQo8YnI+DQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5k IOKAnGlzc+KAnSBjbGFpbXMuPGJyPg0KPGJyPg0KJiM0MzsxIGZvciBhIOKAnHR5cGXigJ0gb3Ig 4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci48YnI+DQo8YnI+DQotLSA8YnI+DQo8 YnI+DQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KPGJyPg0KSWRlbnRpdHkgU2Vydmlj ZXM8YnI+DQo8YnI+DQoqRnJvbTogKklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5j b208L2E+Jmd0Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE08 YnI+DQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZn dDs8YnI+DQoqQ2M6ICpBZGFtIERhd2VzICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7LCAmcXVvdDtt YXRha2UsIG5vdiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdl dD0iX2JsYW5rIj5ub3ZAbWF0YWtlLmpwPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3Qg Jmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlk LWV2ZW50QGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5w aGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KKlN1YmplY3Q6ICpSZTogW0lkLWV2ZW50 XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VU IGlzc3Vlcjxicj4NCjxicj4NCkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMg b2YgZGlzY3Vzc2lvbiBvbiB3aGF0IHNob3VsZCBiZSBpbiAzLjkuPGJyPg0KPGJyPg0KT24gTW9u LCBKdW4gMTIsIDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VA Z29vZ2xlLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsmZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhhbmtzIGZvciB0aGUgcG9pbnRlciBE aWNrLCB2ZXJ5IGdvb2QgdGltaW5nIDotKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIGlz c3VlIGlzIGRlc2NyaWJlZCBieSAmcXVvdDsyLjcuIENyb3NzLUpXVCBDb25mdXNpb24mcXVvdDsg YW5kIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgbWl0aWdhdGlvbiBpcyBpbiAmcXVvdDszLjkuIFVz ZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3I8YnI+DQombmJzcDsgJm5i c3A7IERpZmZlcmVudCBLaW5kcyBvZiBKV1RzJnF1b3Q7LCBzcGVjaWZpY2FsbHkgJnF1b3Q7VXNl IGRpZmZlcmVudCBzZXRzIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyByZXF1aXJlZCBjbGFpbXMuLi4m cXVvdDssICZxdW90O1VzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mPGJy Pg0KJm5ic3A7ICZuYnNwOyBKV1RzLiZxdW90OyBhbmQgJnF1b3Q7VXNlIGRpZmZlcmVudCBpc3N1 ZXJzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4mcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyBJIHN0aWxsIHRoaW5rIHRoYXQgYSAmcXVvdDt0eXBlJnF1b3Q7IGNsYWltIHdvdWxk IGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyBzYWZldHkuPGJy Pg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21h aWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpX VDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2VsZi0yRGlzc3VlZC5pbmZv Xy0zRnAtM0QxNjkwJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2Fp MTE1YyZhbXA7cz1hN1h2WjVqVGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTY5MDwv YT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwg MjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDsmZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMgdG8gYmUgdmVyeSBzaW1p bGFyIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaWQg dG9rZW5zIGJ1dCBJIG5vdyB0aGluayB0aGlzIGlzIGEgYmV0dGVyIHBsYW4uPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwg MjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFr ZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+Jmd0OyZndDsg d3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmIzQzOzEgZXNwZWNpYWxseSBmb3IgJnF1b3Q7dHlwZSZxdW90Ozxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgMjAxNy0wNi0wOSAxMDozMiBHTVQmIzQzOzA5OjAwIFBoaWwgSHVudCAoSURNKTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPiZndDsmZ3Q7Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOzE8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgUGhpbDxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1 cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSB3ZXJlIGEgY291cGxl IG9mIHByb3Bvc2FscyBvbiBob3cgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlzdGluZ3Vpc2ggU0VU cyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBpbjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBz dWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGNvbmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJpdHk8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdnVsbmVyYWJpbGl0aWVzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUgaXMgYWxzbyBhbm90aGVyIGlt cG9ydGFudCByZXF1aXJlbWVudDogdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNFVCBpc3N1ZXIgaW4g c29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm cXVvdDtzdWImcXVvdDsgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcg U0VUczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBhbiBJZFAuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBXaXRoIHRoZXNlIHJlcXVpcmVtZW50 cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9sbG93aW5nOjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gYm90aCAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90 O2lzcyZxdW90OyB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBs ZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGF0IGV2 ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBk aWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O2lzcyZxdW90OyBh bmQgJnF1b3Q7c3ViJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyAtICZxdW90O3N1YiZxdW90OyBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQg dGhlIHRvcCBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNh bWJpZ3VhdGlvbiksIHBsZWFzZSBub3RlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3Nob3VsZCZx dW90OyBhbmQgbm90ICZxdW90O211c3QmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoaXMgc29sdXRpb24gYWxzbyBhbGxvd3Mg ZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGV2ZW50IHR5 cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGVk IHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFuZDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxldmVsPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHRoZXJlIHdpbGwgYmUgbm8gY29sbGlzaW9ucyBvciBhbWJpZ3VpdHkuPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBB bm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGRlZmluZSBhIGNvbXBvc2l0ZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0uIFRoaXMgaXMgbm90 IHNvbHZpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0 Jm5ic3A7IFNFVCBpc3N1ZXIuIEFsc28sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGhhdmluZyB0aGUgc2Ft ZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlu IGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFuZCB5ZXQg YW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBhICZxdW90O3R5cGUmcXVvdDsuIFRoaXMgaXMg bm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwgYW5kIGl0 IGFsc28gaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNvbHZpbmcgdGhlIGRpc3RpbmN0IGlzc3Vl ciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhpcyBpcyBzb21l dGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNv bnNpZGVyLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgVGhvdWdodHM/PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsNCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4 MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4 WUtPQ2QwbXhQUUZKTGh4V0kmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VH SnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1 YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQ UUZKTGh4V0kmYW1wO2U9PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1l dmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdq NzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUti OXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxp bmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklk LWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtk PUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209 VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6 c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSA8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBZGFtIERhd2Vz IHwgU3IuIFByb2R1Y3QgTWFuYWdlciB8PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHw8YSBocmVmPSJ0ZWw6JTJCMSUyMDY1MC0yMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsiPiYj NDM7MSA2NTAtMjE0LTI0MTA8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9InRlbDolMjg2NTAlMjklMjAyMTQtMjQxMCIgdGFyZ2V0 PSJfYmxhbmsiPnRlbDooNjUwKSUyMDIxNC0yNDEwPC9hPiZndDs8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50 QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1w O2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JL MTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7 bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1 R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9h Pjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSA8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgJmx0OzxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19o YXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4 QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmYW1wO3M9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vaGFyZHR3YXJlLmNvbS88L2E+Jmd0Ow0KIG1h aWwgbGlzdCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFybiBhYm91dCBw cm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0K PGJyPg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZh bXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFt cDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9aTc1 VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vaGFyZHR3YXJlLmNvbS88L2E+Jmd0Ow0KIG1haWwgbGlzdCB0byBsZWFy biBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1l dmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdq NzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUti OXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZY Q3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXln N29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1R bDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0 RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0Rm dC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01V N1RtR01TV1dzJmFtcDtlPTwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1l dmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5JZC1ldmVudCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklkLWV2ZW50QGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB05044F0DB071245AE3D4C05EF5C60CY4PR21MB0504namp_-- From nobody Sat Jun 17 14:47:13 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297F2129C32 for ; Sat, 17 Jun 2017 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhTYpyiwlg4I for ; Sat, 17 Jun 2017 14:47:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EE11289B5 for ; Sat, 17 Jun 2017 14:47:07 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5HLkwcL029276 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 17 Jun 2017 21:46:59 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5HLkv97023234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Jun 2017 21:46:57 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5HLkrb3013869; Sat, 17 Jun 2017 21:46:54 GMT Received: from [25.188.127.34] (/24.114.39.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Jun 2017 14:46:51 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-5C64C477-5A1E-4203-93DF-27F3F626124F Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sat, 17 Jun 2017 14:46:48 -0700 Cc: Yaron Sheffer , Justin Richer , Marius Scurtescu , "Richard Backman, Annabelle" , Henk Birkholz , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39! @mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 21:47:12 -0000 --Apple-Mail-5C64C477-5A1E-4203-93DF-27F3F626124F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Comments in line.=20 Phil > On Jun 17, 2017, at 2:06 PM, Mike Jones wrot= e: >=20 > I=E2=80=99m sorry to be slow replying to some messages in this thread. I h= ave a lot of other things on my plate, but I will take the time now to reply= , because I wholeheartedly disagree with some of the statements below and be= lieve it would be severely harmful to the specification and its adoption to a= ct upon them. Specifically: > =20 > I disagree that specific rules should be made for the =E2=80=9Csub=E2=80=9D= claim. Claims usage needs to be up to the application. I know that many o= thers agree with me, because the OpenID Connect working group designed the l= ogout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.htm= l#LogoutToken (which is also used as an example in https://tools.ietf.org/ht= ml/draft-ietf-secevent-token-01#section-2) to use the =E2=80=9Csub=E2=80=9D c= laim in the normal way. Prohibiting this usage would be a completely unnece= ssary breaking change =E2=80=93 as it=E2=80=99s impossible to confuse a logo= ut token with an ID Token, for reasons already cites in this thread. Mike we disagree on this.=20 I and others voted against the OpenId decision to move to implementer status= of OpenId because of this issue and others. Chiefly that secevents had open= issues that would cause breaking changes. =20 You indicated at OpenId as secretary that breaking changes by secevents woul= d NOT be an issue.=20 We also disagree on the scope of use in logout. Recently you indicated we sh= ould define yet another logout.=20 > =20 > (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at https://= tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1. No further =E2= =80=9Ciss=E2=80=9D rules are needed.) It is still an issue that issuer of the subject vs issuer of the token are c= onfused.=20 We have this issue in ietf and openid as far as I am concerned because we ha= ve cases that will issue app logout notices that are fyi's to the idp. Eg ap= p logout vs sso logout.=20 If an app logs out the OP needs to know that the old id token is no good.=20= > =20 > It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be use= d for some profiles to differentiate between kinds of JWTs. Its use should n= ot be mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D functionality by defining another claim with a duplicative meaning= . > =20 > I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CN= o other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D Thi= s reflects a misunderstanding. It=E2=80=99s the *value* of the nonce that s= elf-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is p= resent. Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D wit= hout any risk of conflict, since the nonce value is a cryptographically secu= re random number. > =20 > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d b= e glad to have in-person discussions about these topics there. > =20 > -- Mike > =20 > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or a= ny other claim) or forcing it to be located in a non-standard location makes= about as much sense as arbitrarily saying that, for a particular profile, t= he Latin word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the cl= aim name instead of =E2=80=9Csub=E2=80=9D. Yes, it will completely differen= tiate this profile from others not spelling the claim name this way, but it w= ould certainly be an impediment to the use of standard JWT libraries and to i= nteroperability. > =20 > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 > Sent: Saturday, June 17, 2017 1:45 PM > To: Justin Richer ; Marius Scurtescu > Cc: Richard Backman, Annabelle ; Mike Jones ; Henk Birkholz ; ID Ev= ents Mailing List ; Phil Hunt > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > So to summarize what I'm seeing on this thread: >=20 > Everybody agrees with Marius's short-term solution, specific rules for "su= b" and "iss" that can be defined in the SET spec. >=20 > Almost everybody agrees on a long-term "usage" claim ("type" is taken) tha= t should be defined elsewhere, e.g. in the JWT BCP. >=20 > Did I miss anything? >=20 > By the way, if we do add a "usage" claim, we need to also use it in the SE= T document before it is published. >=20 > Thanks, >=20 > Yaron >=20 > =20 > On 15/06/17 22:08, Justin Richer wrote: > +1 to this as well. > =20 > =E2=80=94 Justin > =20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu wrot= e: > =20 > +1 to what Annabelle said. > =20 > Also, Mike you are missing the other requirement, for RPs to send events t= o an IdP. The iss+sub pair at the top level is broken in this case. >=20 > Marius > =20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wr= ote: > +1 > =20 > Phil >=20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >=20 > Mike, > =20 > Your explanation for why this is a non-problem is dependent upon side effe= cts of elements of OpenID Connect that were not designed to solve this issue= . As a result, I see several issues with it: > 1. The caller of the Token Endpoint is the only party that can be ce= rtain that a nonce-less ID Token is really an ID Token. Any party that the c= aller passes the ID Token off to has no way to verify its provenance. >=20 > 2. Any future ID Token distribution method needs to solve this probl= em again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile tha= t cares about disambiguation has to invent its own solution to the problem. >=20 > =20 > We know from experience that naming collisions and replay attacks are both= things that happen. What=E2=80=99s being proposed is a simple, defensive me= asure against these risks. You brought up JWT libraries: a general solution a= ctually makes it easier to use common libraries for JWT parsing. A =E2=80=9C= usage-aware=E2=80=9D JWT library could handle disambiguation for any JWT pro= file, whereas with the status quo each profile would require unique logic. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Mike Jones > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > Cc: "Richard Backman, Annabelle" , ID Events Mailing L= ist , Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2=80= =99d characterize the proposals in this thread as =E2=80=9Cpremature pessima= tion=E2=80=9D =E2=80=93 making things that can and should be simple complex,= without data showing there=E2=80=99s any need to do so. > =20 > Mandatory solutions are being proposed in this thread to problems that the= re=E2=80=99s no evidence that we actually even have. It=E2=80=99s already b= een established that it=E2=80=99s impossible for a SET to be confused for an= ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/curre= nt/msg00428.html. If people have data showing that this is possible with sp= ecific kinds of Access Tokens or other real JWT deployments, please provide s= pecifics, so that we can use that data to inform appropriate engineering cho= ices on our part. > =20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2= =80=9Csub=E2=80=9D in the normal way, or requiring a type claim, would make p= reviously simple things unnecessarily complex. Yes, then the result is then= different than a normal JWT but a consequence of this is that custom parsin= g code would have to be used, rather than a standard JWT parser. The more u= nwieldy we make it to use SETs, the more likely developers are to just creat= e their own data structures. Keeping it simple is the key to adoption. Sta= ndards are only useful if they are actually used. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Bac= kman, Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu ; Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80= =9Cintend=E2=80=9D? > =20 > To your first question, I think a better analogy would be the X.509 Key Us= age extension: a multi-valued property that declares the intended purpose of= the JWT, and that a recipient may refer to when determining whether to acce= pt a JWT being presented to it in some context. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Marius Scurtescu <= mscurtescu@google.com> > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via "intend= ", "audience", and "scope"? > =20 > "aud" (audience) specifies the target client, but not the intended usage (= access token to authorize resource access or SET to communicate a security e= vent?) > =20 > "scope" is not used by SET. > =20 > I don't know what do you mean by "intend" (or intent)? > =20 > =20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutual= ly exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ens= ure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a= current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cd= ifferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is e= asier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header pa= rameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event on behalf of Dick Hardt > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID Ev= ents Mailing List , "Phil Hunt (IDM)" > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and disti= nct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be in 3= .9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: >=20 > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YK= OCd0mxPQFJLhxWI&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j= 746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D= > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DWPqIpmdKcdpKZXupMf-= xibi5O-t0ZuRpllAzZI6rgjQ&s=3D1XTj1kjyTq7Pz-UjTZmzMyJcVzl1sDGI55seqd9eVfs&e=3D= =20 --Apple-Mail-5C64C477-5A1E-4203-93DF-27F3F626124F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Comments in line. 

Phil

On Jun 17, 2017, at 2:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m sorry to be= slow replying to some messages in this thread.  I have a lot of other t= hings on my plate, but I will take the time now to reply, because I wholehea= rtedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adopt= ion to act upon them.  Specifically:

 

<= /blockquote>

Mike we disagree on this. 

I and others voted against the OpenId decision to move to implementer stat= us of OpenId because of this issue and others. Chiefly that secevents had op= en issues that would cause breaking changes.  

You indicated at OpenId as secretary that breaking changes by secevents wou= ld NOT be an issue. 

We also disagree on the s= cope of use in logout. Recently you indicated we should define yet another l= ogout. 

 


It is still an issue that issuer of the subject= vs issuer of the token are confused. 

We have= this issue in ietf and openid as far as I am concerned because we have case= s that will issue app logout notices that are fyi's to the idp. Eg app logou= t vs sso logout. 

If an app logs out the OP ne= eds to know that the old id token is no good. 

 

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used f= or some profiles to differentiate between kinds of JWTs.  Its use shoul= d not be mandated in the SET spec.  I would oppose duplicating the =E2=80= =9Ctyp=E2=80=9D functionality by defining another claim with a duplicative m= eaning.

 

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other profile of JWT can ever use the "nonce=E2=80= =9D claim.=E2=80=9D  This reflects a misunderstanding.  It=E2= =80=99s the *value* of the nonce that self-secures the JWT =E2=80=93 n= ot that any =E2=80=9Cnonce=E2=80=9D claim is present.  Any and all JWTs can simultaneously use =E2=80=9Cno= nce=E2=80=9D without any risk of conflict, since the nonce value is a crypto= graphically secure random number.

 

Will some of you be at t= he Cloud Identity Summit next week?  I=E2=80=99d be glad to have in-per= son discussions about these topics there.

 

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

 

P.S.  Food for tho= ught:  Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any other claim= ) or forcing it to be located in a non-standard location makes about as much= sense as arbitrarily saying that, for a particular profile, the Latin word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the c= laim name instead of =E2=80=9Csub=E2=80=9D.  Yes, it will completely di= fferentiate this profile from others not spelling the claim name this way, b= ut it would certainly be an impediment to the use of standard JWT libraries and to interoperability.

 

From:<= span style=3D"color:windowtext"> Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.= edu>; Marius Scurtescu <m= scurtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de">henk.birkholz@sit.fraunhof= er.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules for "s= ub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) th= at should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use it in the S= ET document before it is published.

Thanks,

    Yaron

 

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

 

 =E2=80=94 Justin

 

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

 

+1 to what Annabelle said.

 

Also, Mike you are missing the other requirement, for= RPs to send events to an IdP. The iss+sub pair at the top level is broken i= n this case.


Marius

 

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <= phil.hunt@oracle.c= om> wrote:

+1

 

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= o:p>

Mike,

 

Your explanation for why this is a non-problem is dependent upon sid= e effects of elements of OpenID Connect that were not designed to solve this= issue. As a result, I see several issues with it:

1.   &nbs= p;   The caller of the Token Endpoint is the only party that can be certai= n that a nonce-less ID Token is really an ID Token. Any party that the calle= r passes the ID Token off to has no way to verify its provenance.=

2.   &nbs= p;   Any future ID Token distribution method needs to solve this problem a= gain.

3.   &nbs= p;  No other profile of JWT can ever use the "nonce=E2=80=9D claim.<= /o:p>

4.   &nbs= p;  This is only a solution for ID Tokens. Every other JWT profile that c= ares about disambiguation has to invent its own solution to the problem.

 

We know from experience that naming collisions and replay attacks ar= e both things that happen. What=E2=80=99s being proposed is a simple, defens= ive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common= libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library coul= d handle disambiguation for any JWT profile, whereas with the status quo eac= h profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microso= ft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List= <id-event@ietf.or= g>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

You=E2=80=99ve heard of =E2=80=9Cprema= ture optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in t= his thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making thing= s that can and should be simple complex, without data showing there=E2=80=99s any need to do so.<= /span>

 

Mandatory solutions are being proposed= in this thread to problems that there=E2=80=99s no evidence that we actuall= y even have.  It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80= =93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.&nb= sp; If people have data showing that this is possible with specific kinds of= Access Tokens or other real JWT deployments, please provide specifics, so t= hat we can use that data to inform appropriate engineering choices on our part.

 

The proposed =E2=80=9Csolutions=E2=80=9D= , such as prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, or= requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but= a consequence of this is that custom parsing code would have to be used, ra= ther than a standard JWT parser.  The more unwieldy we make it to use S= ETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key t= o adoption.  Standards are only useful if they are actually used.

 

      &n= bsp;            =             &nbs= p;            &n= bsp;   -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.f= raunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D?

 

To your first question, I think a better analogy would be the X.509 K= ey Usage extension: a multi-valued property that declares the intended purpo= se of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it= in some context.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com= >
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunh= ofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend",= "audience", and "scope"?

 

"aud" (audience) specifies the target client, but not the intended u= sage (access token to authorize resource access or SET to communicate a secu= rity event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutually= exclusive set of valid claims and/or header parameters, and enforcing this r= equires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure= that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdif= ferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by t= he spec or not, implementers will ignore this because managing one key is ea= sier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header para= meter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <= adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9= .

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.c= om>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the     mitigation is in "3.9. Use Mutually Exclusive Validation Rules= for
    Different Kinds of JWTs", specifically "Use different sets of<= br>     required claims...", "Use different keys for different kinds o= f
    JWTs." and "Use different issuers for different kinds of JWTs.= ".

    I still think that a "type" claim would bring a lot of clarity= and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID for J= WT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com         <mailto:adawes@google.com>> wrote:

            I was initially a fan of keeping S= ETS to be very similar to
            id tokens but I now think this is a= better plan.

            On Thu, Jun 8, 2017 at 6:56 PM mat= ake, nov <nov@matake.j= p
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "t= ype"

                2017-06-09 10:32 GMT= +09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailt= o:phil.hunt@oracle= .com>>:

                    +1
=
                    Phil

                     = > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <mscurtescu@google.c= om

                   = ; <mailto:mscu= rtescu@google.com>> wrote:
                     = >
                     = > There were a couple of proposals on how to
                    distin= guish SETs from Id Tokens and Access Tokens in
                    such a= way that naive implementations will not
                    confus= e one for the other and open up security
                    vulner= abilities.
                     = >
                     = > There is also another important requirement: the
                    SET is= suer in some cases must be different from the
                    "sub" i= ssuer. This is the case of an RP sending SETs
                    to an I= dP.
                     = >
                     = > With these requirements in mind I propose the
                    follow= ing:
                     = > - both "sub" and "iss" to be defined at the event
                    level<= br>                      = > - "iss" at event level and at top SET level can
                    be dif= ferent
                     = > - "iss" and "sub" at event level can be different
                    across= events in the same SET
                     = > - "sub" should NOT be present at the top SET
                    level (= this solves the disambiguation), please note
                    "shoul= d" and not "must"
                     = >
                     = > This solution also allows different profiles that
                    define= event types to define additional claims
                    relate= d to sub (like email or phone_number) and
                    since a= ll these claims will be at the event level
                    there w= ill be no collisions or ambiguity.
                     = >
                     = > Another proposal (which I supported) was to
                    define= a composite "aud" claim. This is not solving
                    the re= quirement for a distinct  SET issuer. Also,
                    having= the same claim name having different syntax
                    in dif= ferent token types could lead to confusion.
                     = >
                     = > And yet another proposal was to introduce a new
                    claim f= or JWTs that defines a "type". This is not
                    practi= cal in the short term, and it also is not
                    solvin= g the distinct issuer requirement, but I think
                    this i= s something the JWT group should seriously
                    consid= er.
                     = >
                     = > Thoughts?
                     = >
                     = > Marius

                     = > _______________________________________________
                     = > Id-event mailing list

                    &nbs= p;> Id-event@ietf.org= <mailto:Id-event@= ietf.org>
                     = >
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_= listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk= KY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuut= Bx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKO= Cd0mxPQFJLhxWI&e=3D

                    ______= _________________________________________
                    Id-eve= nt mailing list
                    Id-event@ietf.org <m= ailto:Id-event@ietf.o= rg>
                    https://www.ietf.org/mailman/listinfo/id-event

                ____________________= ___________________________
                Id-event mailing lis= t
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product Manager |= adawes@google.com=
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            __________________________________= _____________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.c= om/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id= -event

 




_______________________________________________
Id-event mailing list
Id-event@ietf.org

https://www.ietf.org/mailman/listin=
fo/id-event

 

= --Apple-Mail-5C64C477-5A1E-4203-93DF-27F3F626124F-- From nobody Sat Jun 17 15:00:14 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EDC12940F for ; Sat, 17 Jun 2017 15:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WDWYce7xWnl for ; Sat, 17 Jun 2017 15:00:06 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0136.outbound.protection.outlook.com [104.47.34.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DC71293FD for ; Sat, 17 Jun 2017 15:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qS8b0TNypNc40JJNjFvDTq6I8ubjFjl7DGoaFyu6Aqo=; b=FvfBkemcfGbZ46K8NpL0C7Hn8yOBZHNKNWSitXmFeO6aDhk6KZd7NWknq0W04VZMRpZupyHCG+zm6stzgH5z0OOMw8yeDFoBW+szmiNwxGZoIPityv2mhsaBKd8V/hl1xYLcy2BQuYUlE4elulXJ1pK+oQr5Xb+VpFXVtN07CqU= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0632.namprd21.prod.outlook.com (10.175.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Sat, 17 Jun 2017 22:00:04 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1199.007; Sat, 17 Jun 2017 22:00:03 +0000 From: Mike Jones To: "Phil Hunt (IDM)" CC: Yaron Sheffer , Justin Richer , Marius Scurtescu , "Richard Backman, Annabelle" , Henk Birkholz , "ID Events Mailing List" Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAAAQ5CAABD6AIAAAKzA Date: Sat, 17 Jun 2017 22:00:02 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39! @mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-17T14:59:58.3056057-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0632; 7:VjzFehv6kIzTZVdn16iw8PGyjil5Uz4cogOy8GHtPNQtM4ipLOmUgz2Xmx161kYI3/NRt65pyfzOqG7YpmaeeVlRgpLVC6pm1qIMMS1e2wQlERwzTXmlhLiHrVUOSUnGIIn6aNzli93wBhVLQYnbAwpIU8N88yOPtjzdelK/L7fk3SxuckceYyBHMSXvReZbGjCm2rwx3pVlxjy5Qq9JpzDK5JaY/C2/Gfa/IsVGCTFpVbOBqcvj4n2XCD+NQ40ORalCEiVbjmHO+pOEjGrLSwLwj29Lhsse5oaWgsmD5FYkrrPjTWUGn++i1gEP2do0uhQgSA5ug+CxsE/E8tLKnam6SM+QIcSFcLrOAvGgJkJ8D6fgMv0LM3APDi+UDpDKHnpECMoe0xCP6uA0ys6EceREcs2qoXJkwaH3B+5MayXQ/aqEFrscghfpVmvlj1TQbq5jj/tSS7gp00QA4ST/pYEPod5nOUKUTpKJIfKq5TIKuRl8sZ8P59IaR0fDQawCe2occja3KmjwmiDYtomHlgqneRhtm/8g1jSc8dhfsgxfLtwnanzHdVTlD8Xd/fFuy3J41ZywFLNxrJBdxXbfAAKd7FX10DMpcSGd+qMJQIUnnhAPNpO150klkKJpsryzHh7K8A37bCbE0ed1KAl41DxyKNCN0qVLNbX1ZMVTAg5T/uR60WvRc58xqWUylb1VP5z92ZYNNcUtXDWELYU7swG6E0yFTmHwcp6L4M4q3x5WunTP5IjY/O9/CZFsZMc86d1nz5Hn8uDzwg3LZePrS4UdbHkQ20MYbRiw55hRfUXsl1eLwt8/0z0PGlzVmHDM x-ms-office365-filtering-correlation-id: f0f434bf-2737-4c05-ae0b-08d4b5cc34da x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:CY4PR21MB0632; x-ms-traffictypediagnostic: CY4PR21MB0632: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(131327999870524)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(47284530071512)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0632; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0632; x-forefront-prvs: 034119E4F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(209900001)(377454003)(377424004)(51914003)(24454002)(97736004)(790700001)(3846002)(4326008)(19609705001)(189998001)(39060400002)(110136004)(81166006)(55016002)(33656002)(6306002)(7696004)(102836003)(6916009)(14454004)(10090500001)(8676002)(8936002)(229853002)(6246003)(53546009)(6436002)(122556002)(54906002)(2950100002)(2906002)(86362001)(53946003)(86612001)(9686003)(3280700002)(575784001)(236005)(16200700003)(76176999)(77096006)(3660700001)(25786009)(54896002)(53376002)(53936002)(99286003)(38730400002)(606005)(74316002)(5660300001)(10290500003)(478600001)(54356999)(66066001)(7906003)(5005710100001)(7736002)(93886004)(6116002)(72206003)(2900100001)(8990500004)(6506006)(966005)(50986999)(561944003)(68736007)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0632; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05047D23D9A9853AB83C7067F5C60CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2017 22:00:02.9535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0632 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 22:00:13 -0000 --_000_CY4PR21MB05047D23D9A9853AB83C7067F5C60CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVwbGllcyBpbmxpbmUgbWFya2VkIHdpdGggTWlrZT7igKYNCg0KRnJvbTogUGhpbCBIdW50IChJ RE0pIFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBTYXR1cmRheSwgSnVuZSAx NywgMjAxNyAyOjQ3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29v Z2xlLmNvbT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29t PjsgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT47IElEIEV2 ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1l dmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0 IFNFVCBpc3N1ZXINCg0KQ29tbWVudHMgaW4gbGluZS4NCg0KUGhpbA0KDQpPbiBKdW4gMTcsIDIw MTcsIGF0IDI6MDYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJ4oCZbSBzb3JyeSB0 byBiZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUgbWVzc2FnZXMgaW4gdGhpcyB0aHJlYWQuICBJIGhh dmUgYSBsb3Qgb2Ygb3RoZXIgdGhpbmdzIG9uIG15IHBsYXRlLCBidXQgSSB3aWxsIHRha2UgdGhl IHRpbWUgbm93IHRvIHJlcGx5LCBiZWNhdXNlIEkgd2hvbGVoZWFydGVkbHkgZGlzYWdyZWUgd2l0 aCBzb21lIG9mIHRoZSBzdGF0ZW1lbnRzIGJlbG93IGFuZCBiZWxpZXZlIGl0IHdvdWxkIGJlIHNl dmVyZWx5IGhhcm1mdWwgdG8gdGhlIHNwZWNpZmljYXRpb24gYW5kIGl0cyBhZG9wdGlvbiB0byBh Y3QgdXBvbiB0aGVtLiAgU3BlY2lmaWNhbGx5Og0KDQoNCiAgKiAgIEkgZGlzYWdyZWUgdGhhdCBz cGVjaWZpYyBydWxlcyBzaG91bGQgYmUgbWFkZSBmb3IgdGhlIOKAnHN1YuKAnSBjbGFpbS4gIENs YWltcyB1c2FnZSBuZWVkcyB0byBiZSB1cCB0byB0aGUgYXBwbGljYXRpb24uICBJIGtub3cgdGhh dCBtYW55IG90aGVycyBhZ3JlZSB3aXRoIG1lLCBiZWNhdXNlIHRoZSBPcGVuSUQgQ29ubmVjdCB3 b3JraW5nIGdyb3VwIGRlc2lnbmVkIHRoZSBsb2dvdXQgdG9rZW4gaW4gaHR0cDovL29wZW5pZC5u ZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFja2NoYW5uZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9r ZW48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX29w ZW5pZC5uZXRfc3BlY3Nfb3BlbmlkLTJEY29ubmVjdC0yRGJhY2tjaGFubmVsLTJEMS01RjAtMkQw NC5odG1sLTIzTG9nb3V0VG9rZW4mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0 Q19sTElHayZtPVdQcUlwbWRLY2RwS1pYdXBNZi14aWJpNU8tdDBadVJwbGxBelpJNnJnalEmcz1C aXh2WnlXcFI5MHhGZDNIRWY0cDFnSzVTaEgtZHotYUYwY0NVOGJrR1ZnJmU9PiAod2hpY2ggaXMg YWxzbyB1c2VkIGFzIGFuIGV4YW1wbGUgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFm dC0yRGlldGYtMkRzZWNldmVudC0yRHRva2VuLTJEMDEtMjNzZWN0aW9uLTJEMiZkPUR3TUdhUSZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1 Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09V1BxSXBtZEtjZHBLWlh1cE1mLXhp Ymk1Ty10MFp1UnBsbEF6Wkk2cmdqUSZzPWlXLTdSZUtGek9MQ3JBNTZRczZFelNfS3h6NUhhalJ5 b3o5S0toYlhCT00mZT0+KSB0byB1c2UgdGhlIOKAnHN1YuKAnSBjbGFpbSBpbiB0aGUgbm9ybWFs IHdheS4gIFByb2hpYml0aW5nIHRoaXMgdXNhZ2Ugd291bGQgYmUgYSBjb21wbGV0ZWx5IHVubmVj ZXNzYXJ5IGJyZWFraW5nIGNoYW5nZSDigJMgYXMgaXTigJlzIGltcG9zc2libGUgdG8gY29uZnVz ZSBhIGxvZ291dCB0b2tlbiB3aXRoIGFuIElEIFRva2VuLCBmb3IgcmVhc29ucyBhbHJlYWR5IGNp dGVzIGluIHRoaXMgdGhyZWFkLg0KDQpNaWtlIHdlIGRpc2FncmVlIG9uIHRoaXMuDQoNCkkgYW5k IG90aGVycyB2b3RlZCBhZ2FpbnN0IHRoZSBPcGVuSWQgZGVjaXNpb24gdG8gbW92ZSB0byBpbXBs ZW1lbnRlciBzdGF0dXMgb2YgT3BlbklkIGJlY2F1c2Ugb2YgdGhpcyBpc3N1ZSBhbmQgb3RoZXJz LiBDaGllZmx5IHRoYXQgc2VjZXZlbnRzIGhhZCBvcGVuIGlzc3VlcyB0aGF0IHdvdWxkIGNhdXNl IGJyZWFraW5nIGNoYW5nZXMuDQoNCllvdSBpbmRpY2F0ZWQgYXQgT3BlbklkIGFzIHNlY3JldGFy eSB0aGF0IGJyZWFraW5nIGNoYW5nZXMgYnkgc2VjZXZlbnRzIHdvdWxkIE5PVCBiZSBhbiBpc3N1 ZS4NCg0KTWlrZT4gIFllcywgdGhlIHdvcmtpbmcgZ3JvdXAgY2FuIGRlY2lkZSB0byBtYWtlIGJy ZWFraW5nIGNoYW5nZXMuICBJdCBjYW4gYWxzbyBkZWNpZGUgbm90IHRvLiAgT3BlbklEIENvbm5l Y3QgaGFzIHN1Y2NlZWRlZCAoYXQgbGVhc3QgaW4gcGFydCkgYmVjYXVzZSBpdCBoYXMga2VwdCBz aW1wbGUgdGhpbmdzIHNpbXBsZS4gIEkgd2lsbCBjb250aW51ZSB0byBiZSBhIHRpcmVsZXNzIGFk dm9jYXRlIGZvciB0aGF0IGRlc2lnbiBwcmluY2lwbGUsIGluY2x1ZGluZyBmb3IgU0VULg0KDQpX ZSBhbHNvIGRpc2FncmVlIG9uIHRoZSBzY29wZSBvZiB1c2UgaW4gbG9nb3V0LiBSZWNlbnRseSB5 b3UgaW5kaWNhdGVkIHdlIHNob3VsZCBkZWZpbmUgeWV0IGFub3RoZXIgbG9nb3V0Lg0KDQpNaWtl PiAgV2hhdCBJIHNhaWQgaW4gdGhlIGNvbnZlcnNhdGlvbiB5b3XigJlyZSByZWZlcnJpbmcgdG8g aXMgdGhhdCBhIGxvZ291dCBldmVudCB0aGF04oCZcyBhbHdheXMgc2VudCBmcm9tIHRoZSBJZFAg dG8gYSBSUCBpcyBtb3JlIHNwZWNpZmljIHRoYW4gb25lIHRoYXQgbWlnaHQgYmUgc2VudCBmcm9t IGFueW9uZSB0byBhbnlvbmUgZWxzZS4gIFRoZSBsYXR0ZXIgbmVlZHMgbW9yZSBpbmZvcm1hdGlv biwgYW5kIHNvIGNvdWxkIGJlIGRlZmluZWQgZm9yIHRob3NlIGFkZGl0aW9uYWwgdXNlIGNhc2Vz LCBpZiBuZWVkZWQuICBUaGUgT3BlbklEIEJhY2stQ2hhbm5lbCBsb2dvdXQgY2FzZSBpcyB0aGUg Zm9ybWVyLCBhbmQgc28gaW5jbHVkZXMgZXhhY3RseSB0aGUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5 IGZvciB0aGF0IHVzZSBjYXNlLg0KDQoNCiAgKg0KDQoNCiAgKiAgIChJIGFncmVlIHdpdGggdGhl IOKAnGlzc+KAnSBydWxlcyBhbHJlYWR5IGluIHBsYWNlIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMi4xPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5v cmdfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRHRva2VuLTJEMDEtMjNzZWN0aW9uLTJE Mi4xJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1XUHFJcG1k S2NkcEtaWHVwTWYteGliaTVPLXQwWnVScGxsQXpaSTZyZ2pRJnM9Ul9JUThETzVDRlJOcWhDakhp SFNpcnd2VEhHbE5Ua3hNSmZMamZ3dGN2WSZlPT4uICBObyBmdXJ0aGVyIOKAnGlzc+KAnSBydWxl cyBhcmUgbmVlZGVkLikNCg0KSXQgaXMgc3RpbGwgYW4gaXNzdWUgdGhhdCBpc3N1ZXIgb2YgdGhl IHN1YmplY3QgdnMgaXNzdWVyIG9mIHRoZSB0b2tlbiBhcmUgY29uZnVzZWQuDQoNCk1pa2U+ICBU aGUgU0VUIHNwZWMgYWxyZWFkeSBzYXlzIHRoYXQgdGhlIHRvcC1sZXZlbCDigJxpc3PigJ0gY2xh aW0gcmVmZXJzIHRvIHRoZSBldmVudCBpc3N1ZXIuICBUaGVyZeKAmXMgYWxyZWFkeSBubyBhbWJp Z3VpdHksIHNvIG5vIGNoYW5nZSBpcyBuZWVkZWQuDQoNCldlIGhhdmUgdGhpcyBpc3N1ZSBpbiBp ZXRmIGFuZCBvcGVuaWQgYXMgZmFyIGFzIEkgYW0gY29uY2VybmVkIGJlY2F1c2Ugd2UgaGF2ZSBj YXNlcyB0aGF0IHdpbGwgaXNzdWUgYXBwIGxvZ291dCBub3RpY2VzIHRoYXQgYXJlIGZ5aSdzIHRv IHRoZSBpZHAuIEVnIGFwcCBsb2dvdXQgdnMgc3NvIGxvZ291dC4NCg0KSWYgYW4gYXBwIGxvZ3Mg b3V0IHRoZSBPUCBuZWVkcyB0byBrbm93IHRoYXQgdGhlIG9sZCBpZCB0b2tlbiBpcyBubyBnb29k Lg0KDQpNaWtlPiBUaGVyZeKAmXMgYWxyZWFkeSBhIG1lc3NhZ2UgZGVmaW5lZCBmb3IgdGhhdCB1 c2UgY2FzZSB0aGF04oCZcyBpbiBwcm9kdWN0aW9uIHVzZS4gIFNlZSBodHRwczovL29wZW5pZC5u ZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3Qtc2Vzc2lvbi0xXzAuaHRtbCNSUExvZ291dC4gIE5vIGFk ZGl0aW9uYWwgcHJvdG9jb2wgd29yayBpcyBuZWVkZWQgdG8gYWNoaWV2ZSB0aGlzLg0KDQoNCiAg Kg0KDQoNCiAgKiAgIEl04oCZcyBmaW5lIGZvciB0aGUg4oCcdHlw4oCdIGhlYWRlciBwYXJhbWV0 ZXIgdG8gYmUgdXNlZCBmb3Igc29tZSBwcm9maWxlcyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4g a2luZHMgb2YgSldUcy4gIEl0cyB1c2Ugc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBpbiB0aGUgU0VU IHNwZWMuICBJIHdvdWxkIG9wcG9zZSBkdXBsaWNhdGluZyB0aGUg4oCcdHlw4oCdIGZ1bmN0aW9u YWxpdHkgYnkgZGVmaW5pbmcgYW5vdGhlciBjbGFpbSB3aXRoIGEgZHVwbGljYXRpdmUgbWVhbmlu Zy4NCg0KDQogICogICBJ4oCZbGwgYWxzbyByZXNwb25kIHRvIEFubmFiZWxsZeKAmXMgYXNzZXJ0 aW9uIHRoYXQg4oCcTm8gb3RoZXIgcHJvZmlsZSBvZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAibm9u Y2XigJ0gY2xhaW0u4oCdICBUaGlzIHJlZmxlY3RzIGEgbWlzdW5kZXJzdGFuZGluZy4gIEl04oCZ cyB0aGUgKnZhbHVlKiBvZiB0aGUgbm9uY2UgdGhhdCBzZWxmLXNlY3VyZXMgdGhlIEpXVCDigJMg bm90IHRoYXQgYW55IOKAnG5vbmNl4oCdIGNsYWltIGlzIHByZXNlbnQuICBBbnkgYW5kIGFsbCBK V1RzIGNhbiBzaW11bHRhbmVvdXNseSB1c2Ug4oCcbm9uY2XigJ0gd2l0aG91dCBhbnkgcmlzayBv ZiBjb25mbGljdCwgc2luY2UgdGhlIG5vbmNlIHZhbHVlIGlzIGEgY3J5cHRvZ3JhcGhpY2FsbHkg c2VjdXJlIHJhbmRvbSBudW1iZXIuDQoNCldpbGwgc29tZSBvZiB5b3UgYmUgYXQgdGhlIENsb3Vk IElkZW50aXR5IFN1bW1pdCBuZXh0IHdlZWs/ICBJ4oCZZCBiZSBnbGFkIHRvIGhhdmUgaW4tcGVy c29uIGRpc2N1c3Npb25zIGFib3V0IHRoZXNlIHRvcGljcyB0aGVyZS4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5T LiAgRm9vZCBmb3IgdGhvdWdodDogIFByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIChv ciBhbnkgb3RoZXIgY2xhaW0pIG9yIGZvcmNpbmcgaXQgdG8gYmUgbG9jYXRlZCBpbiBhIG5vbi1z dGFuZGFyZCBsb2NhdGlvbiBtYWtlcyBhYm91dCBhcyBtdWNoIHNlbnNlIGFzIGFyYml0cmFyaWx5 IHNheWluZyB0aGF0LCBmb3IgYSBwYXJ0aWN1bGFyIHByb2ZpbGUsIHRoZSBMYXRpbiB3b3JkIGZv ciBzdWJqZWN0IOKAnHN1YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5hbWUg aW5zdGVhZCBvZiDigJxzdWLigJ0uICBZZXMsIGl0IHdpbGwgY29tcGxldGVseSBkaWZmZXJlbnRp YXRlIHRoaXMgcHJvZmlsZSBmcm9tIG90aGVycyBub3Qgc3BlbGxpbmcgdGhlIGNsYWltIG5hbWUg dGhpcyB3YXksIGJ1dCBpdCB3b3VsZCBjZXJ0YWlubHkgYmUgYW4gaW1wZWRpbWVudCB0byB0aGUg dXNlIG9mIHN0YW5kYXJkIEpXVCBsaWJyYXJpZXMgYW5kIHRvIGludGVyb3BlcmFiaWxpdHkuDQoN CkZyb206IFlhcm9uIFNoZWZmZXIgW21haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb21dDQpTZW50 OiBTYXR1cmRheSwgSnVuZSAxNywgMjAxNyAxOjQ1IFBNDQpUbzogSnVzdGluIFJpY2hlciA8anJp Y2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjsgTWFyaXVzIFNjdXJ0ZXNjdSA8 bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pg0KQ2M6 IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tPj47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IEhlbmsgQmlya2hvbHog PGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGU+PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5v cmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj47IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyDQoNCg0KU28gdG8gc3VtbWFyaXplIHdoYXQgSSdtIHNlZWluZyBvbiB0aGlzIHRo cmVhZDoNCg0KRXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRp b24sIHNwZWNpZmljIHJ1bGVzIGZvciAic3ViIiBhbmQgImlzcyIgdGhhdCBjYW4gYmUgZGVmaW5l ZCBpbiB0aGUgU0VUIHNwZWMuDQoNCkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10 ZXJtICJ1c2FnZSIgY2xhaW0gKCJ0eXBlIiBpcyB0YWtlbikgdGhhdCBzaG91bGQgYmUgZGVmaW5l ZCBlbHNld2hlcmUsIGUuZy4gaW4gdGhlIEpXVCBCQ1AuDQoNCkRpZCBJIG1pc3MgYW55dGhpbmc/ DQoNCkJ5IHRoZSB3YXksIGlmIHdlIGRvIGFkZCBhICJ1c2FnZSIgY2xhaW0sIHdlIG5lZWQgdG8g YWxzbyB1c2UgaXQgaW4gdGhlIFNFVCBkb2N1bWVudCBiZWZvcmUgaXQgaXMgcHVibGlzaGVkLg0K DQpUaGFua3MsDQoNCiAgICBZYXJvbg0KDQpPbiAxNS8wNi8xNyAyMjowOCwgSnVzdGluIFJpY2hl ciB3cm90ZToNCisxIHRvIHRoaXMgYXMgd2VsbC4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSnVuIDE1 LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5j b208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQorMSB0byB3aGF0IEFu bmFiZWxsZSBzYWlkLg0KDQpBbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIgcmVx dWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzK3N1YiBw YWlyIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS4NCg0KTWFyaXVzDQoN Ck9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQorMQ0K DQpQaGlsDQoNCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+ PiB3cm90ZToNCk1pa2UsDQoNCllvdXIgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGlzIGlzIGEgbm9u LXByb2JsZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3RzIG9mIGVsZW1lbnRzIG9mIE9w ZW5JRCBDb25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4g QXMgYSByZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGggaXQ6DQoNCjEuICAgICAgIFRo ZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQgY2Fu IGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRv a2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRv IGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLg0KDQoyLiAgICAgICBBbnkgZnV0 dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9i bGVtIGFnYWluLg0KDQozLiAgICAgIE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVz ZSB0aGUgIm5vbmNl4oCdIGNsYWltLg0KDQo0LiAgICAgIFRoaXMgaXMgb25seSBhIHNvbHV0aW9u IGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBwcm9maWxlIHRoYXQgY2FyZXMgYWJvdXQg ZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMgb3duIHNvbHV0aW9uIHRvIHRoZSBwcm9i bGVtLg0KDQpXZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5hbWluZyBjb2xsaXNpb25zIGFu ZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBoYXBwZW4uIFdoYXTigJlzIGJl aW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRoZXNl IHJpc2tzLiBZb3UgYnJvdWdodCB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRpb24g YWN0dWFsbHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24gbGlicmFyaWVzIGZvciBKV1Qg cGFyc2luZy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFyeSBjb3VsZCBoYW5kbGUgZGlz YW1iaWd1YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVhcyB3aXRoIHRoZSBzdGF0dXMg cXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy4NCg0KLS0NCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQtZXZl bnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5 LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRl c2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpDYzogIlJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9s ekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2Vu IGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpZb3XigJl2ZSBoZWFyZCBvZiDi gJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiAgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9w b3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBt YWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhv dXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBkbyBzby4NCg0KTWFuZGF0b3J5 IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhpcyB0aHJlYWQgdG8gcHJvYmxlbXMg dGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBhY3R1YWxseSBldmVuIGhhdmUuICBJ dOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9y IGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDigJMgc2VlIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQyOC5odG1s PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0Mjgu aHRtbCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JL MTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdH VTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWVLTFRRUG1ZclYzVGhmRGJu OTBTQ3M1NVVST1RQaW5fbGdjNlJkcjVYb3cmZT0+LiAgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93 aW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBU b2tlbnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNp Zmljcywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0gYXBwcm9wcmlhdGUg ZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC4NCg0KVGhlIHByb3Bvc2VkIOKAnHNvbHV0 aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0aGUg bm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2aW91 c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4LiAgWWVzLCB0aGVuIHRoZSBy ZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVu Y2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1 c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuICBUaGUgbW9yZSB1bndpZWxk eSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxvcGVycyBhcmUg dG8ganVzdCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4gIEtlZXBpbmcgaXQgc2lt cGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uICBTdGFuZGFyZHMgYXJlIG9ubHkgdXNlZnVsIGlm IHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNTozMyBQTQ0KVG86IE1hcml1cyBT Y3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFp bHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KQ2M6IElEIEV2ZW50cyBNYWls aW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1 c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hvaW5nIE1hcml1c+KAmXMgcXVlc3Rp b246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT8NCg0KVG8g eW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRo ZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0 IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVj aXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNjZXB0IGEg SldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuDQoNCi0tDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50 IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnPj4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNv bTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEp1bmUgMTMs IDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NCkNj OiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KT24gVHVlLCBK dW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+IHdy b3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFudGljcyB3b3VsZCAidXNhZ2Ui IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEgImludGVuZCIsICJhdWRpZW5j ZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNwZWNpZmllcyB0aGUgdGFyZ2V0 IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tlbiB0byBhdXRo b3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNlY3VyaXR5IGV2 ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoNCkkgZG9uJ3Qga25vdyB3aGF0 IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0KDQoNCg0KDQpIZW5rDQoNCk9u IDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOg0K VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsgdGhlIGFzc3VtcHRp b25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dlIGNhbuKAmXQgZ3VhcmFudGVl IHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHNl dCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQgZW5mb3JjaW5n IHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFpbeKAnSBhcHBy b2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBjYW7igJl0IGJl IG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3SXQgaXMgdW5yZWFs aXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVu dCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRh dGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVj YXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50 IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy4NCg0K KzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1ldGVy Lg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCklkZW50aXR5IFNlcnZpY2Vz DQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCipEYXRlOiAqTW9u ZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1hcml1cyBTY3VydGVzY3UgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCipDYzog KkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4+ LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPj4sIElE IEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBp ZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29sdXRp b24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXIN Cg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNjdXNzaW9uIG9u IHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4gMTIsIDIwMTcgYXQgMzoxNSBQ TSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1 cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRoZSBwb2ludGVy IERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUgaXMgZGVzY3JpYmVk IGJ5ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBtaXRpZ2F0aW9uIGlz IGluICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3INCiAg ICBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNlIGRpZmZlcmVudCBz ZXRzIG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJlbnQga2V5cyBmb3Ig ZGlmZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZlcmVudCBpc3N1ZXJz IGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGlsbCB0aGluayB0aGF0 IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kDQogICAgc2Fm ZXR5Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQ TSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtlIGFuZCBJIGp1c3Qg cHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5p bmZvLz9wPTE2OTA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZkPUR3TUdhUSZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZzPWE3WHZaNWpUYnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpNY1VJ VVEmZT0+DQoNCiAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3 ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAg PG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+Pj4gd3Jv dGU6DQoNCiAgICAgICAgICAgIEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMg dG8gYmUgdmVyeSBzaW1pbGFyIHRvDQogICAgICAgICAgICBpZCB0b2tlbnMgYnV0IEkgbm93IHRo aW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi4NCg0KICAgICAgICAgICAgT24gVGh1LCBKdW4gOCwg MjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0 YWtlLmpwPg0KICAgICAgICAgICAgPG1haWx0bzpub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0 YWtlLmpwPj4+IHdyb3RlOg0KDQogICAgICAgICAgICAgICAgKzEgZXNwZWNpYWxseSBmb3IgInR5 cGUiDQoNCiAgICAgICAgICAgICAgICAyMDE3LTA2LTA5IDEwOjMyIEdNVCswOTowMCBQaGlsIEh1 bnQgKElETSkNCiAgICAgICAgICAgICAgICA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbT4+PjoNCg0KICAgICAgICAgICAgICAgICAgICArMQ0KDQogICAg ICAgICAgICAgICAgICAgIFBoaWwNCg0KDQogICAgICAgICAgICAgICAgICAgICA+IE9uIEp1biA4 LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAgICAgICAgICAgICAg IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCiAg ICAgICAgICAgICAgICAgICAgPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbT4+PiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgID4NCiAg ICAgICAgICAgICAgICAgICAgID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24g aG93IHRvDQogICAgICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tl bnMgYW5kIEFjY2VzcyBUb2tlbnMgaW4NCiAgICAgICAgICAgICAgICAgICAgc3VjaCBhIHdheSB0 aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAgICAgICAgICAgICBj b25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5DQogICAgICAgICAg ICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAg ICAgICAgICAgICAgICAgID4gVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJl bWVudDogdGhlDQogICAgICAgICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBt dXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAic3ViIiBpc3N1 ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQogICAgICAgICAgICAg ICAgICAgIHRvIGFuIElkUC4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAg ICAgICAgID4gV2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlDQog ICAgICAgICAgICAgICAgICAgIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgID4gLSBi b3RoICJzdWIiIGFuZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudA0KICAgICAgICAg ICAgICAgICAgICBsZXZlbA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGF0IGV2ZW50 IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbg0KICAgICAgICAgICAgICAgICAgICBiZSBk aWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQgInN1YiIgYXQgZXZl bnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICBhY3Jvc3MgZXZl bnRzIGluIHRoZSBzYW1lIFNFVA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJzdWIiIHNob3Vs ZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAgICAgICAgICBsZXZl bCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUNCiAgICAgICAg ICAgICAgICAgICAgInNob3VsZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAgICAgICAgICAgICAg ID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZm ZXJlbnQgcHJvZmlsZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgZXZlbnQgdHlw ZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAgICAgICAgIHJlbGF0 ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kDQogICAgICAgICAgICAg ICAgICAgIHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWwN CiAgICAgICAgICAgICAgICAgICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmln dWl0eS4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5v dGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAgICAgICAgICAgICAg ICAgICBkZWZpbmUgYSBjb21wb3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmcN CiAgICAgICAgICAgICAgICAgICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0ICBTRVQg aXNzdWVyLiBBbHNvLA0KICAgICAgICAgICAgICAgICAgICBoYXZpbmcgdGhlIHNhbWUgY2xhaW0g bmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRheA0KICAgICAgICAgICAgICAgICAgICBpbiBkaWZm ZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uDQogICAgICAgICAgICAg ICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3Nh bCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3DQogICAgICAgICAgICAgICAgICAgIGNsYWltIGZvciBK V1RzIHRoYXQgZGVmaW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAgICAgICAgICAgICAg ICAgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3QNCiAgICAg ICAgICAgICAgICAgICAgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBi dXQgSSB0aGluaw0KICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldU IGdyb3VwIHNob3VsZCBzZXJpb3VzbHkNCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIuDQog ICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRob3VnaHRzPw0K ICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBNYXJpdXMNCg0K ICAgICAgICAgICAgICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudCBtYWlsaW5nIGxp c3QNCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgIGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdK eFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlS aUhxV2dmeHFtZyZzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0km ZT0NCg0KICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVudCBtYWlsaW5nIGxp c3QNCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50 QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZz4+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9 RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hz aG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRF S2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgSWQtZXZl bnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1 Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQogICAgICAgICAgICAtLQ0KICAgICAgICAg ICAgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfGFkYXdlc0Bnb29nbGUuY29tPG1h aWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4gfCsxIDY1MC0yMTQtMjQxMDx0ZWw6JTJC MSUyMDY1MC0yMTQtMjQxMD4NCiAgICAgICAgICAgIDx0ZWw6KDY1MCklMjAyMTQtMjQxMDx0ZWw6 JTI4NjUwJTI5JTIwMjE0LTI0MTA+Pg0KDQogICAgICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGlu ZyBsaXN0DQogICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pj4NCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdU bUdNU1dXcyZlPT4NCg0KICAgICAgICAtLQ0KICAgICAgICBTdWJzY3JpYmUgdG8gdGhlIEhBUkRU V0FSRSA8aHR0cDovL2hhcmR0d2FyZS5jb20vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJW ODAmZT0+PiBtYWlsIGxpc3QgdG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3 b3JraW5nIG9uIQ0KDQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6 Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTEx NWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFp bCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBt YWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpq V3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkx MTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50 IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZl bnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NE ZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1Rt R01TV1dzJmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1XUHFJcG1kS2NkcEtaWHVwTWYteGliaTVP LXQwWnVScGxsQXpaSTZyZ2pRJnM9MVhUajFranlUcTdQei1ValRabXpNeUpjVnpsMXNER0k1NXNl cWQ5ZVZmcyZlPT4NCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KDQpJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1XUHFJcG1k S2NkcEtaWHVwTWYteGliaTVPLXQwWnVScGxsQXpaSTZyZ2pRJnM9MVhUajFranlUcTdQei1ValRa bXpNeUpjVnpsMXNER0k1NXNlcWQ5ZVZmcyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZ VHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smbT1XUHFJcG1kS2NkcEtaWHVwTWYteGliaTVPLXQwWnVScGxsQXpaSTZyZ2pRJnM9MVhUajFr anlUcTdQei1ValRabXpNeUpjVnpsMXNER0k1NXNlcWQ5ZVZmcyZlPQ0K --_000_CY4PR21MB05047D23D9A9853AB83C7067F5C60CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAubTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFy YWdyYXBoLCBsaS5tOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tOTA5 NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV85MDk0 MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoyMTY1OTgyMzA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yNzE3 NzgyNjQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo4NzQwMDY0NDI7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjgxNzE1MTM0Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1s aXN0LWlkOjEwMjA4MTY3OTg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjEyNDU2MTkxODIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxp c3QtaWQ6MTI2ODE5OTk4NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODIxNTY1MDA0O30NCkBs aXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTQ1NTQ0NTAzODsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTYxOTU4MDk2MDt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjE3 NDk4NDM1NzQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDE4NDU0MTUyO30NCkBsaXN0IGw1 OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDU6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDYNCgl7bXNvLWxpc3QtaWQ6MjA5ODgyMTk1OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6NzY4MTMyMTAyO30NCkBsaXN0IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDY6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDY6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5SZXBsaWVzIGlubGlu ZSBtYXJrZWQgd2l0aCBNaWtlJmd0O+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPiBQaGlsIEh1bnQgKElETSkgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVuZSAxNywgMjAxNyAyOjQ3IFBNPGJyPg0KPGI+VG86 PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBK dXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7OyBNYXJpdXMgU2N1cnRlc2N1ICZs dDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAm bHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs7IEhlbmsgQmlya2hvbHogJmx0O2hlbmsuYmlya2hv bHpAc2l0LmZyYXVuaG9mZXIuZGUmZ3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDtpZC1l dmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gc29s dXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q29tbWVudHMgaW4gbGluZS4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCk9uIEp1biAxNywgMjAxNywgYXQgMjowNiBQTSwgTWlrZSBKb25lcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J 4oCZbSBzb3JyeSB0byBiZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUgbWVzc2FnZXMgaW4gdGhpcyB0 aHJlYWQuJm5ic3A7IEkgaGF2ZSBhIGxvdCBvZiBvdGhlciB0aGluZ3Mgb24gbXkgcGxhdGUsIGJ1 dCBJIHdpbGwgdGFrZSB0aGUgdGltZSBub3cgdG8gcmVwbHksIGJlY2F1c2UgSSB3aG9sZWhlYXJ0 ZWRseSBkaXNhZ3JlZSB3aXRoIHNvbWUgb2YgdGhlIHN0YXRlbWVudHMgYmVsb3cNCiBhbmQgYmVs aWV2ZSBpdCB3b3VsZCBiZSBzZXZlcmVseSBoYXJtZnVsIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGFu ZCBpdHMgYWRvcHRpb24gdG8gYWN0IHVwb24gdGhlbS4mbmJzcDsgU3BlY2lmaWNhbGx5Ojwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6IzAwMjA2MDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KSSBk aXNhZ3JlZSB0aGF0IHNwZWNpZmljIHJ1bGVzIHNob3VsZCBiZSBtYWRlIGZvciB0aGUg4oCcc3Vi 4oCdIGNsYWltLiAmbmJzcDtDbGFpbXMgdXNhZ2UgbmVlZHMgdG8gYmUgdXAgdG8gdGhlIGFwcGxp Y2F0aW9uLiZuYnNwOyBJIGtub3cgdGhhdCBtYW55IG90aGVycyBhZ3JlZSB3aXRoIG1lLCBiZWNh dXNlIHRoZSBPcGVuSUQgQ29ubmVjdCB3b3JraW5nIGdyb3VwIGRlc2lnbmVkIHRoZSBsb2dvdXQg dG9rZW4gaW4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX19vcGVuaWQubmV0X3NwZWNzX29wZW5pZC0yRGNvbm5lY3QtMkRiYWNrY2hh bm5lbC0yRDEtNUYwLTJEMDQuaHRtbC0yM0xvZ291dFRva2VuJmFtcDtkPUR3TUdhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209V1BxSXBtZEtjZHBLWlh1 cE1mLXhpYmk1Ty10MFp1UnBsbEF6Wkk2cmdqUSZhbXA7cz1CaXh2WnlXcFI5MHhGZDNIRWY0cDFn SzVTaEgtZHotYUYwY0NVOGJrR1ZnJmFtcDtlPSI+DQpodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9v cGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAtMDQuaHRtbCNMb2dvdXRUb2tlbjwvYT4gKHdo aWNoIGlzIGFsc28gdXNlZCBhcyBhbiBleGFtcGxlIGluDQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0 bWxfZHJhZnQtMkRpZXRmLTJEc2VjZXZlbnQtMkR0b2tlbi0yRDAxLTIzc2VjdGlvbi0yRDImYW1w O2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JL MTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7 bT1XUHFJcG1kS2NkcEtaWHVwTWYteGliaTVPLXQwWnVScGxsQXpaSTZyZ2pRJmFtcDtzPWlXLTdS ZUtGek9MQ3JBNTZRczZFelNfS3h6NUhhalJ5b3o5S0toYlhCT00mYW1wO2U9Ij4NCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24t MjwvYT4pIHRvIHVzZSB0aGUg4oCcc3Vi4oCdIGNsYWltIGluIHRoZSBub3JtYWwgd2F5LiZuYnNw OyBQcm9oaWJpdGluZyB0aGlzIHVzYWdlIHdvdWxkIGJlIGEgY29tcGxldGVseSB1bm5lY2Vzc2Fy eSBicmVha2luZyBjaGFuZ2Ug4oCTIGFzIGl04oCZcyBpbXBvc3NpYmxlIHRvIGNvbmZ1c2UgYSBs b2dvdXQgdG9rZW4gd2l0aCBhbiBJRCBUb2tlbiwgZm9yDQogcmVhc29ucyBhbHJlYWR5IGNpdGVz IGluIHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPk1pa2Ugd2UgZGlzYWdyZWUg b24gdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5JIGFuZCBvdGhlcnMgdm90ZWQgYWdhaW5zdCB0aGUgT3Bl bklkIGRlY2lzaW9uIHRvIG1vdmUgdG8gaW1wbGVtZW50ZXIgc3RhdHVzIG9mIE9wZW5JZCBiZWNh dXNlIG9mIHRoaXMgaXNzdWUgYW5kIG90aGVycy4gQ2hpZWZseSB0aGF0IHNlY2V2ZW50cyBoYWQg b3BlbiBpc3N1ZXMgdGhhdCB3b3VsZCBjYXVzZSBicmVha2luZyBjaGFuZ2VzLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPllvdSBpbmRpY2F0ZWQgYXQgT3BlbklkIGFzIHNlY3JldGFyeSB0aGF0IGJy ZWFraW5nIGNoYW5nZXMgYnkgc2VjZXZlbnRzIHdvdWxkIE5PVCBiZSBhbiBpc3N1ZS4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1pa2Um Z3Q7Jm5ic3A7IFllcywgdGhlIHdvcmtpbmcgZ3JvdXAgY2FuIGRlY2lkZSB0byBtYWtlIGJyZWFr aW5nIGNoYW5nZXMuJm5ic3A7IEl0IGNhbiBhbHNvIGRlY2lkZSBub3QgdG8uJm5ic3A7IE9wZW5J RCBDb25uZWN0IGhhcyBzdWNjZWVkZWQgKGF0IGxlYXN0IGluIHBhcnQpIGJlY2F1c2UgaXQgaGFz IGtlcHQgc2ltcGxlIHRoaW5ncyBzaW1wbGUuJm5ic3A7IEkgd2lsbCBjb250aW51ZSB0byBiZQ0K IGEgdGlyZWxlc3MgYWR2b2NhdGUgZm9yIHRoYXQgZGVzaWduIHByaW5jaXBsZSwgaW5jbHVkaW5n IGZvciBTRVQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij5XZSBhbHNvIGRpc2FncmVlIG9uIHRoZSBzY29wZSBvZiB1c2UgaW4gbG9nb3V0LiBS ZWNlbnRseSB5b3UgaW5kaWNhdGVkIHdlIHNob3VsZCBkZWZpbmUgeWV0IGFub3RoZXIgbG9nb3V0 LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+TWlrZSZndDsmbmJzcDsgV2hhdCBJIHNhaWQgaW4gdGhlIGNvbnZlcnNhdGlvbiB5b3XigJly ZSByZWZlcnJpbmcgdG8gaXMgdGhhdCBhIGxvZ291dCBldmVudCB0aGF04oCZcyBhbHdheXMgc2Vu dCBmcm9tIHRoZSBJZFAgdG8gYSBSUCBpcyBtb3JlIHNwZWNpZmljIHRoYW4gb25lIHRoYXQgbWln aHQgYmUgc2VudCBmcm9tIGFueW9uZSB0byBhbnlvbmUgZWxzZS4mbmJzcDsgVGhlIGxhdHRlciBu ZWVkcw0KIG1vcmUgaW5mb3JtYXRpb24sIGFuZCBzbyBjb3VsZCBiZSBkZWZpbmVkIGZvciB0aG9z ZSBhZGRpdGlvbmFsIHVzZSBjYXNlcywgaWYgbmVlZGVkLiZuYnNwOyBUaGUgT3BlbklEIEJhY2st Q2hhbm5lbCBsb2dvdXQgY2FzZSBpcyB0aGUgZm9ybWVyLCBhbmQgc28gaW5jbHVkZXMgZXhhY3Rs eSB0aGUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IGZvciB0aGF0IHVzZSBjYXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzMiPg0KPG86cD4mbmJzcDs8L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwyIGxldmVsMSBsZm8zIj4NCihJIGFncmVlIHdpdGggdGhlIOKAnGlzc+KAnSBydWxlcyBh bHJlYWR5IGluIHBsYWNlIGF0IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYt MkRzZWNldmVudC0yRHRva2VuLTJEMDEtMjNzZWN0aW9uLTJEMi4xJmFtcDtkPUR3TUdhUSZhbXA7 Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTVi aVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209V1BxSXBtZEtjZHBL Wlh1cE1mLXhpYmk1Ty10MFp1UnBsbEF6Wkk2cmdqUSZhbXA7cz1SX0lROERPNUNGUk5xaENqSGlI U2lyd3ZUSEdsTlRreE1KZkxqZnd0Y3ZZJmFtcDtlPSI+DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0wMSNzZWN0aW9uLTIuMTwvYT4uJm5ic3A7 IE5vIGZ1cnRoZXIg4oCcaXNz4oCdIHJ1bGVzIGFyZSBuZWVkZWQuKTxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPkl0IGlzIHN0aWxsIGFuIGlzc3VlIHRoYXQgaXNzdWVyIG9mIHRoZSBzdWJqZWN0IHZz IGlzc3VlciBvZiB0aGUgdG9rZW4gYXJlIGNvbmZ1c2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWlrZSZndDsmbmJzcDsgVGhlIFNF VCBzcGVjIGFscmVhZHkgc2F5cyB0aGF0IHRoZSB0b3AtbGV2ZWwg4oCcaXNz4oCdIGNsYWltIHJl ZmVycyB0byB0aGUgZXZlbnQgaXNzdWVyLiZuYnNwOyBUaGVyZeKAmXMgYWxyZWFkeSBubyBhbWJp Z3VpdHksIHNvIG5vIGNoYW5nZSBpcyBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5XZSBoYXZlIHRoaXMgaXNzdWUgaW4gaWV0ZiBh bmQgb3BlbmlkIGFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCBiZWNhdXNlIHdlIGhhdmUgY2FzZXMg dGhhdCB3aWxsIGlzc3VlIGFwcCBsb2dvdXQgbm90aWNlcyB0aGF0IGFyZSBmeWkncyB0byB0aGUg aWRwLiBFZyBhcHAgbG9nb3V0IHZzIHNzbyBsb2dvdXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5J ZiBhbiBhcHAgbG9ncyBvdXQgdGhlIE9QIG5lZWRzIHRvIGtub3cgdGhhdCB0aGUgb2xkIGlkIHRv a2VuIGlzIG5vIGdvb2QuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5NaWtlJmd0OyBUaGVyZeKAmXMgYWxyZWFkeSBhIG1lc3NhZ2UgZGVm aW5lZCBmb3IgdGhhdCB1c2UgY2FzZSB0aGF04oCZcyBpbiBwcm9kdWN0aW9uIHVzZS4mbmJzcDsg U2VlDQo8YSBocmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3Qtc2Vz c2lvbi0xXzAuaHRtbCNSUExvZ291dCI+aHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1j b25uZWN0LXNlc3Npb24tMV8wLmh0bWwjUlBMb2dvdXQ8L2E+LiZuYnNwOyBObyBhZGRpdGlvbmFs IHByb3RvY29sIHdvcmsgaXMgbmVlZGVkIHRvIGFjaGlldmUgdGhpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVs MSBsZm8zIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMyI+DQpJdOKAmXMgZmluZSBmb3IgdGhlIOKAnHR5cOKAnSBoZWFkZXIgcGFy YW1ldGVyIHRvIGJlIHVzZWQgZm9yIHNvbWUgcHJvZmlsZXMgdG8gZGlmZmVyZW50aWF0ZSBiZXR3 ZWVuIGtpbmRzIG9mIEpXVHMuJm5ic3A7IEl0cyB1c2Ugc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBp biB0aGUgU0VUIHNwZWMuJm5ic3A7IEkgd291bGQgb3Bwb3NlIGR1cGxpY2F0aW5nIHRoZSDigJx0 eXDigJ0gZnVuY3Rpb25hbGl0eSBieSBkZWZpbmluZyBhbm90aGVyIGNsYWltIHdpdGggYSBkdXBs aWNhdGl2ZSBtZWFuaW5nLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMyI+DQpJ4oCZbGwgYWxzbyByZXNwb25kIHRvIEFubmFiZWxsZeKAmXMgYXNz ZXJ0aW9uIHRoYXQg4oCcPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5ObyBvdGhlciBwcm9maWxl IG9mIEpXVCBjYW4gZXZlciB1c2UgdGhlICZxdW90O25vbmNl4oCdIGNsYWltLjwvc3Bhbj7igJ0m bmJzcDsgVGhpcyByZWZsZWN0cyBhIG1pc3VuZGVyc3RhbmRpbmcuJm5ic3A7IEl04oCZcyB0aGUg KjxiPnZhbHVlPC9iPiogb2YgdGhlIG5vbmNlIHRoYXQgc2VsZi1zZWN1cmVzIHRoZSBKV1Qg4oCT IG5vdCB0aGF0IGFueSDigJxub25jZeKAnQ0KIGNsYWltIGlzIHByZXNlbnQuJm5ic3A7IEFueSBh bmQgYWxsIEpXVHMgY2FuIHNpbXVsdGFuZW91c2x5IHVzZSDigJxub25jZeKAnSB3aXRob3V0IGFu eSByaXNrIG9mIGNvbmZsaWN0LCBzaW5jZSB0aGUgbm9uY2UgdmFsdWUgaXMgYSBjcnlwdG9ncmFw aGljYWxseSBzZWN1cmUgcmFuZG9tIG51bWJlci48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+V2lsbCBzb21lIG9mIHlvdSBiZSBhdCB0aGUgQ2xvdWQgSWRlbnRpdHkgU3VtbWl0 IG5leHQgd2Vlaz8mbmJzcDsgSeKAmWQgYmUgZ2xhZCB0byBoYXZlIGluLXBlcnNvbiBkaXNjdXNz aW9ucyBhYm91dCB0aGVzZSB0b3BpY3MgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UC5TLiZuYnNwOyBGb29kIGZv ciB0aG91Z2h0OiZuYnNwOyBQcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSAob3IgYW55 IG90aGVyIGNsYWltKSBvciBmb3JjaW5nIGl0IHRvIGJlIGxvY2F0ZWQgaW4gYSBub24tc3RhbmRh cmQgbG9jYXRpb24gbWFrZXMgYWJvdXQgYXMgbXVjaCBzZW5zZSBhcyBhcmJpdHJhcmlseSBzYXlp bmcgdGhhdCwgZm9yIGEgcGFydGljdWxhciBwcm9maWxlLA0KIHRoZSBMYXRpbiB3b3JkIGZvciBz dWJqZWN0IOKAnHN1YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5hbWUgaW5z dGVhZCBvZiDigJxzdWLigJ0uJm5ic3A7IFllcywgaXQgd2lsbCBjb21wbGV0ZWx5IGRpZmZlcmVu dGlhdGUgdGhpcyBwcm9maWxlIGZyb20gb3RoZXJzIG5vdCBzcGVsbGluZyB0aGUgY2xhaW0gbmFt ZSB0aGlzIHdheSwgYnV0IGl0IHdvdWxkIGNlcnRhaW5seSBiZSBhbiBpbXBlZGltZW50IHRvIHRo ZSB1c2Ugb2Ygc3RhbmRhcmQgSldUDQogbGlicmFyaWVzIGFuZCB0byBpbnRlcm9wZXJhYmlsaXR5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+IFlhcm9uIFNoZWZmZXIgWzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBn bWFpbC5jb20iPm1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFNhdHVyZGF5LCBKdW5lIDE3LCAyMDE3IDE6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1 c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiPmpyaWNoZXJA bWl0LmVkdTwvYT4mZ3Q7OyBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNj dXJ0ZXNjdUBnb29nbGUuY29tIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDs7IE1pa2UgSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVm PSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSI+aGVuay5iaXJraG9sekBz aXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0Ozxh IGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0 OzsgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1l dmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0 IFNFVCBpc3N1ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5TbyB0byBzdW1tYXJpemUg d2hhdCBJJ20gc2VlaW5nIG9uIHRoaXMgdGhyZWFkOjxvOnA+PC9vOnA+PC9wPg0KPHA+RXZlcnli b2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmljIHJ1 bGVzIGZvciAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0aGF0IGNhbiBiZSBk ZWZpbmVkIGluIHRoZSBTRVQgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjxwPkFsbW9zdCBldmVyeWJv ZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICZxdW90O3VzYWdlJnF1b3Q7IGNsYWltICgmcXVvdDt0 eXBlJnF1b3Q7IGlzIHRha2VuKSB0aGF0IHNob3VsZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5n LiBpbiB0aGUgSldUIEJDUC48bzpwPjwvbzpwPjwvcD4NCjxwPkRpZCBJIG1pc3MgYW55dGhpbmc/ PG86cD48L286cD48L3A+DQo8cD5CeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAmcXVvdDt1c2Fn ZSZxdW90OyBjbGFpbSwgd2UgbmVlZCB0byBhbHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50 IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8cD5UaGFua3MsPG86cD48 L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmljaGVyIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byB0aGlz IGFzIHdlbGwuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRl c2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIj5tc2N1cnRlc2N1 QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byB3aGF0IEFubmFiZWxsZSBzYWlkLiA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIE1pa2UgeW91IGFyZSBt aXNzaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudCwgZm9yIFJQcyB0byBzZW5kIGV2ZW50cyB0byBh biBJZFAuIFRoZSBpc3MmIzQzO3N1YiBwYWlyIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGlu IHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcml1czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0s IFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2ln bmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBsZU1haWxTaWduYXR1cmUiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaWtl LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91ciBleHBsYW5hdGlvbiBmb3Igd2h5IHRo aXMgaXMgYSBub24tcHJvYmxlbSBpcyBkZXBlbmRlbnQgdXBvbiBzaWRlIGVmZmVjdHMgb2YgZWxl bWVudHMgb2YgT3BlbklEIENvbm5lY3QgdGhhdCB3ZXJlIG5vdCBkZXNpZ25lZCB0byBzb2x2ZSB0 aGlzIGlzc3VlLiBBcyBhIHJlc3VsdCwgSSBzZWUgc2V2ZXJhbA0KIGlzc3VlcyB3aXRoIGl0Ojxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFn cmFwaCI+MS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+VGhlIGNhbGxlciBvZiB0aGUgVG9rZW4gRW5kcG9pbnQgaXMgdGhlIG9u bHkgcGFydHkgdGhhdCBjYW4gYmUgY2VydGFpbiB0aGF0IGEgbm9uY2UtbGVzcyBJRCBUb2tlbiBp cyByZWFsbHkgYW4gSUQgVG9rZW4uIEFueSBwYXJ0eSB0aGF0IHRoZSBjYWxsZXIgcGFzc2VzIHRo ZSBJRCBUb2tlbiBvZmYgdG8gaGFzIG5vIHdheSB0byB2ZXJpZnkgaXRzIHByb3ZlbmFuY2UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdy YXBoIj4yLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj5BbnkgZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVl ZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCI+My48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+Tm8gb3RoZXIgcHJvZmls ZSBvZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAmcXVvdDtub25jZeKAnSBjbGFpbS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiPjQu PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PlRoaXMgaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBw cm9maWxlIHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMg b3duIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ V2Uga25vdyBmcm9tIGV4cGVyaWVuY2UgdGhhdCBuYW1pbmcgY29sbGlzaW9ucyBhbmQgcmVwbGF5 IGF0dGFja3MgYXJlIGJvdGggdGhpbmdzIHRoYXQgaGFwcGVuLiBXaGF04oCZcyBiZWluZyBwcm9w b3NlZCBpcyBhIHNpbXBsZSwgZGVmZW5zaXZlIG1lYXN1cmUgYWdhaW5zdCB0aGVzZSByaXNrcy4g WW91IGJyb3VnaHQNCiB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRpb24gYWN0dWFs bHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24gbGlicmFyaWVzIGZvciBKV1QgcGFyc2lu Zy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFyeSBjb3VsZCBoYW5kbGUgZGlzYW1iaWd1 YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVhcyB3aXRoIHRoZSBzdGF0dXMgcXVvIGVh Y2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOg0KPC9iPklkLWV2ZW50ICZsdDs8 YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWlrZSBKb25l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPldlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyBhdCAxOjE2IFBNPGJyPg0KPGI+VG86IDwv Yj5NYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5h QGFtYXpvbi5jb208L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnRAaWV0Zi5v cmc8L2E+Jmd0OywgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hv bHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0g c29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBp c3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPllvdeKAmXZlIGhlYXJkIG9mIOKAnHByZW1hdHVy ZSBvcHRpbWl6YXRpb27igJ0uJm5ic3A7IEnigJlkIGNoYXJhY3Rlcml6ZSB0aGUgcHJvcG9zYWxz IGluIHRoaXMgdGhyZWFkIGFzIOKAnHByZW1hdHVyZSBwZXNzaW1hdGlvbuKAnSDigJMgbWFraW5n IHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hvdWxkDQogYmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhvdXQg ZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBkbyBzby48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NYW5kYXRvcnkgc29sdXRpb25zIGFyZSBiZWluZyBw cm9wb3NlZCBpbiB0aGlzIHRocmVhZCB0byBwcm9ibGVtcyB0aGF0IHRoZXJl4oCZcyBubyBldmlk ZW5jZSB0aGF0IHdlIGFjdHVhbGx5IGV2ZW4gaGF2ZS4mbmJzcDsgSXTigJlzIGFscmVhZHkgYmVl biBlc3RhYmxpc2hlZA0KIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJlIGNv bmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDigJMgc2VlIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRh cmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZhbXA7ZD1Ed01HYVEm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9ZUtMVFFQbVlyVjNUaGZE Ym45MFNDczU1VVJPVFBpbl9sZ2M2UmRyNVhvdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cw MDQyOC5odG1sPC9hPi4mbmJzcDsgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93aW5nIHRoYXQgdGhp cyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBUb2tlbnMgb3Igb3Ro ZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNpZmljcywgc28gdGhh dCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0NCiBhcHByb3ByaWF0ZSBlbmdpbmVlcmlu ZyBjaG9pY2VzIG9uIG91ciBwYXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPlRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPigJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcg dGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1hbCB3YXksIG9yIHJlcXVpcmluZyBhIHR5 cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNseSBzaW1wbGUgdGhpbmdzIHVubmVjZXNzYXJp bHkNCiBjb21wbGV4LiZuYnNwOyBZZXMsIHRoZW4gdGhlIHJlc3VsdCBpcyB0aGVuIGRpZmZlcmVu dCB0aGFuIGEgbm9ybWFsIEpXVCBidXQgYSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgY3Vz dG9tIHBhcnNpbmcgY29kZSB3b3VsZCBoYXZlIHRvIGJlIHVzZWQsIHJhdGhlciB0aGFuIGEgc3Rh bmRhcmQgSldUIHBhcnNlci4mbmJzcDsgVGhlIG1vcmUgdW53aWVsZHkgd2UgbWFrZSBpdCB0byB1 c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVsb3BlcnMgYXJlIHRvDQoganVzdCBjcmVhdGUg dGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4mbmJzcDsgS2VlcGluZyBpdCBzaW1wbGUgaXMgdGhl IGtleSB0byBhZG9wdGlvbi4mbmJzcDsgU3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0aGV5 IGFyZSBhY3R1YWxseSB1c2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IElkLWV2ZW50IFs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMywgMjAxNyA1OjMzIFBNPGJyPg0KPGI+VG86 PC9iPiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs7IEhl bmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwv YT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVm PSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9u IGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RWNob2luZyBNYXJpdXPi gJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieSDigJxpbnRlbmTi gJ0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyB5b3VyIGZpcnN0IHF1ZXN0aW9uLCBJ IHRoaW5rIGEgYmV0dGVyIGFuYWxvZ3kgd291bGQgYmUgdGhlIFguNTA5IEtleSBVc2FnZSBleHRl bnNpb246IGEgbXVsdGktdmFsdWVkIHByb3BlcnR5IHRoYXQgZGVjbGFyZXMgdGhlIGludGVuZGVk IHB1cnBvc2Ugb2YgdGhlIEpXVCwgYW5kIHRoYXQgYSByZWNpcGllbnQNCiBtYXkgcmVmZXIgdG8g d2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpXVCBiZWluZyBwcmVzZW50ZWQg dG8gaXQgaW4gc29tZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFubmFiZWxs ZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPkZyb206DQo8L2I+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBo cmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSnVuZSAx MywgMjAxNyBhdCAxMTowNSBBTTxicj4NCjxiPlRvOiA8L2I+SGVuayBCaXJraG9seiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2Js YW5rIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+DQo8Yj5DYzog PC9iPklEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tl biBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVl LCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5r LmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QW5kIGEgMm5kIHF1ZXN0aW9uLjxicj4NCjxicj4NCldoYXQgc2Vt YW50aWNzIHdvdWxkICZxdW90O3VzYWdlJnF1b3Q7IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3Qg Y292ZXJlZCB2aWEgJnF1b3Q7aW50ZW5kJnF1b3Q7LCAmcXVvdDthdWRpZW5jZSZxdW90OywgYW5k ICZxdW90O3Njb3BlJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O2F1ZCZxdW90OyAoYXVkaWVuY2UpIHNw ZWNpZmllcyB0aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFj Y2VzcyB0b2tlbiB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5p Y2F0ZSBhIHNlY3VyaXR5IGV2ZW50Pyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O3Njb3BlJnF1b3Q7IGlzIG5vdCB1c2VkIGJ5 IFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgZG9uJ3Qga25vdyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICZxdW90O2ludGVuZCZxdW90 OyAob3IgaW50ZW50KT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KPGJyPg0KSGVuazxicj4NCjxicj4NCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0s IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyITxicj4NCjxicj4NCkkg dGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOjxicj4NCjxi cj4NCsK3V2UgY2Fu4oCZdCBndWFyYW50ZWUgdGhhdCBldmVyeSB0eXBlIG9mIEpXVCB3aWxsIGhh dmUgYSBtdXR1YWxseSBleGNsdXNpdmUgc2V0IG9mIHZhbGlkIGNsYWltcyBhbmQvb3IgaGVhZGVy IHBhcmFtZXRlcnMsIGFuZCBlbmZvcmNpbmcgdGhpcyByZXF1aXJlcyBhIOKAnGZhaWwgb24gYW4g dW5yZWNvZ25pemVkIGNsYWlt4oCdIGFwcHJvYWNoIHRvIGVuc3VyZSB0aGF0IEpXVHMgZnJvbSBz b21lIGZ1dHVyZSBzcGVjIGNhbuKAmXQgYmUgbWlzdGFrZW4gZm9yIEpXVHMNCiBmcm9tIGEgY3Vy cmVudCBzcGVjLjxicj4NCjxicj4NCsK3SXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxl bWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQg a2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5v dCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5 IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50IGtleXMuPGJyPg0KPGJyPg0KwrdE aXR0byBmb3Ig4oCcYXVk4oCdIGFuZCDigJxpc3PigJ0gY2xhaW1zLjxicj4NCjxicj4NCiYjNDM7 MSBmb3IgYSDigJx0eXBl4oCdIG9yIOKAnHVzYWdl4oCdIGNsYWltL2hlYWRlciBwYXJhbWV0ZXIu PGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxicj4N Cjxicj4NCklkZW50aXR5IFNlcnZpY2VzPGJyPg0KPGJyPg0KKkZyb206ICpJZC1ldmVudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERpY2sgSGFy ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQoqRGF0ZTogKk1vbmRheSwgSnVu ZSAxMiwgMjAxNyBhdCAzOjE4IFBNPGJyPg0KKlRvOiAqTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3Vy dGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KKkNjOiAqQWRhbSBEYXdlcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2ds ZS5jb208L2E+Jmd0OywgJnF1b3Q7bWF0YWtlLCBub3YmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwvYT4mZ3Q7LCBJ RCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90O1Bo aWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCipT dWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25m dXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8YnI+DQo8YnI+DQpBZ3JlZWQuIE5vdGUgdGhh dCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hhdCBzaG91bGQgYmUgaW4g My45Ljxicj4NCjxicj4NCk9uIE1vbiwgSnVuIDEyLCAyMDE3IGF0IDM6MTUgUE0sIE1hcml1cyBT Y3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VA Z29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRo YW5rcyBmb3IgdGhlIHBvaW50ZXIgRGljaywgdmVyeSBnb29kIHRpbWluZyA6LSk8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IFRoZSBpc3N1ZSBpcyBkZXNjcmliZWQgYnkgJnF1b3Q7Mi43LiBDcm9z cy1KV1QgQ29uZnVzaW9uJnF1b3Q7IGFuZCB0aGU8YnI+DQombmJzcDsgJm5ic3A7IG1pdGlnYXRp b24gaXMgaW4gJnF1b3Q7My45LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZlIFZhbGlkYXRpb24gUnVs ZXMgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyZxdW90Oywg c3BlY2lmaWNhbGx5ICZxdW90O1VzZSBkaWZmZXJlbnQgc2V0cyBvZjxicj4NCiZuYnNwOyAmbmJz cDsgcmVxdWlyZWQgY2xhaW1zLi4uJnF1b3Q7LCAmcXVvdDtVc2UgZGlmZmVyZW50IGtleXMgZm9y IGRpZmZlcmVudCBraW5kcyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgSldUcy4mcXVvdDsgYW5kICZx dW90O1VzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuJnF1 b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBzdGlsbCB0aGluayB0aGF0IGEgJnF1b3Q7 dHlwZSZxdW90OyBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFuZDxicj4NCiZu YnNwOyAmbmJzcDsgc2FmZXR5Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgTWFyaXVz PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6NTkgUE0s IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFyb24sIE1pa2UgYW5kIEkganVzdCBwdWJs aXNoZWQgYW4gQkNQIElEIGZvciBKV1Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1 Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFs N2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9YTdYdlo1alRidEEydmpmYUhJTWJ2RU9w U0JCbEJwZHNEa0lUWk1jVUlVUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9zZWxm LWlzc3VlZC5pbmZvLz9wPTE2OTA8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTowMiBQTSBBZGFtIERhd2VzICZsdDs8YSBo cmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29v Z2xlLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNA Z29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHdhcyBpbml0aWFsbHkgYSBmYW4gb2Yga2VlcGlu ZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGlkIHRva2VucyBidXQgSSBub3cgdGhpbmsgdGhpcyBpcyBhIGJl dHRlciBwbGFuLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBtYXRha2UsIG5vdiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5rIj5ub3ZAbWF0YWtlLmpw PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5rIj5ub3ZA bWF0YWtlLmpwPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxIGVzcGVjaWFsbHkg Zm9yICZxdW90O3R5cGUmcXVvdDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMTctMDYtMDkgMTA6MzIgR01UJiM0Mzsw OTowMCBQaGlsIEh1bnQgKElETSk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7Jmd0Ozo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJiM0MzsxPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBoaWw8YnI+DQo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBPbiBKdW4gOCwgMjAxNywgYXQgNjoyOCBQTSwgTWFyaXVz IFNjdXJ0ZXNjdTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVz Y3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3Rl Ojxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsgVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2VzcyBUb2tlbnMg aW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxlbWVudGF0aW9u cyB3aWxsIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFu ZCBvcGVuIHVwIHNlY3VyaXR5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZ1bG5lcmFiaWxpdGllcy48YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRo ZXJlIGlzIGFsc28gYW5vdGhlciBpbXBvcnRhbnQgcmVxdWlyZW1lbnQ6IHRoZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBTRVQgaXNzdWVyIGluIHNvbWUgY2FzZXMgbXVzdCBiZSBkaWZmZXJlbnQgZnJvbSB0 aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3ViJnF1b3Q7IGlzc3Vlci4gVGhpcyBpcyB0aGUg Y2FzZSBvZiBhbiBSUCBzZW5kaW5nIFNFVHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gYW4gSWRQLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg V2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGZvbGxvd2luZzo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtIGJvdGggJnF1 b3Q7c3ViJnF1b3Q7IGFuZCAmcXVvdDtpc3MmcXVvdDsgdG8gYmUgZGVmaW5lZCBhdCB0aGUgZXZl bnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAt ICZxdW90O2lzcyZxdW90OyBhdCBldmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBsZXZlbCBjYW48 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgYmUgZGlmZmVyZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsgLSAmcXVvdDtpc3MmcXVvdDsgYW5kICZxdW90O3N1YiZxdW90OyBhdCBldmVudCBsZXZlbCBj YW4gYmUgZGlmZmVyZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFjcm9zcyBldmVudHMgaW4gdGhlIHNh bWUgU0VUPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSAmcXVvdDtzdWImcXVvdDsgc2hv dWxkIE5PVCBiZSBwcmVzZW50IGF0IHRoZSB0b3AgU0VUPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxldmVs ICh0aGlzIHNvbHZlcyB0aGUgZGlzYW1iaWd1YXRpb24pLCBwbGVhc2Ugbm90ZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmcXVvdDtzaG91bGQmcXVvdDsgYW5kIG5vdCAmcXVvdDttdXN0JnF1b3Q7PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGlz IHNvbHV0aW9uIGFsc28gYWxsb3dzIGRpZmZlcmVudCBwcm9maWxlcyB0aGF0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGRlZmluZSBldmVudCB0eXBlcyB0byBkZWZpbmUgYWRkaXRpb25hbCBjbGFpbXM8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgcmVsYXRlZCB0byBzdWIgKGxpa2UgZW1haWwgb3IgcGhvbmVfbnVtYmVy KSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3aWxsIGJlIGF0 IHRoZSBldmVudCBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVyZSB3aWxsIGJlIG5vIGNvbGxp c2lvbnMgb3IgYW1iaWd1aXR5Ljxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsgQW5vdGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQp IHdhcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWZpbmUgYSBjb21wb3NpdGUgJnF1b3Q7YXVkJnF1 b3Q7IGNsYWltLiBUaGlzIGlzIG5vdCBzb2x2aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSByZXF1 aXJlbWVudCBmb3IgYSBkaXN0aW5jdCZuYnNwOyBTRVQgaXNzdWVyLiBBbHNvLDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBoYXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRh eDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBpbiBkaWZmZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0 byBjb25mdXNpb24uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBBbmQgeWV0IGFub3RoZXIgcHJvcG9zYWwgd2FzIHRvIGludHJvZHVjZSBh IG5ldzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjbGFpbSBmb3IgSldUcyB0aGF0IGRlZmluZXMgYSAmcXVv dDt0eXBlJnF1b3Q7LiBUaGlzIGlzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcmFjdGljYWwgaW4g dGhlIHNob3J0IHRlcm0sIGFuZCBpdCBhbHNvIGlzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzb2x2 aW5nIHRoZSBkaXN0aW5jdCBpc3N1ZXIgcmVxdWlyZW1lbnQsIGJ1dCBJIHRoaW5rPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHRoaXMgaXMgc29tZXRoaW5nIHRoZSBKV1QgZ3JvdXAgc2hvdWxkIHNlcmlvdXNs eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBjb25zaWRlci48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRob3VnaHRzPzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgTWFyaXVzPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBJZC1ldmVudCBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVu dEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZhbXA7cz01eFFx dkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNB ZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDty PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209Sm11dXRC eDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZhbXA7cz01eFFxdkJpWFo2SWo5 TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmFtcDtlPTwvYT48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2 ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21a dUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwv YT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklk LWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6 ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6 Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dX cyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgLS0gPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfDxhIGhyZWY9Im1h aWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29t PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YWRhd2VzQGdvb2dsZS5jb208L2E+Jmd0OyB8PGEgaHJlZj0idGVsOiUyQjElMjA2NTAtMjE0LTI0 MTAiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzEgNjUwLTIxNC0yNDEwPC9hPjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJ0ZWw6JTI4NjUw JTI5JTIwMjE0LTI0MTAiIHRhcmdldD0iX2JsYW5rIj50ZWw6KDY1MCklMjAyMTQtMjQxMDwvYT4m Z3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxp c3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRm Lm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlf M3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01T V1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLS0gPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YnNjcmliZSB0byB0 aGUgSEFSRFRXQVJFICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1R bDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4 aGgxVE9yUU9VWDJYTVlCZXJWODAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2hhcmR0 d2FyZS5jb20vPC9hPiZndDsNCiBtYWlsIGxpc3QgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxicj4NCjxicj4N Cjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFICZs dDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAw WV8zelJvYWkxMTVjJmFtcDtzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlC ZXJWODAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2hhcmR0d2FyZS5jb20vPC9hPiZn dDsNCiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxi cj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21a dUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm YW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1V c2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pz c0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZl bnRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm YW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1Q N21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lD QWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0Za WVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT08L2E+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209V1BxSXBtZEtjZHBLWlh1cE1m LXhpYmk1Ty10MFp1UnBsbEF6Wkk2cmdqUSZhbXA7cz0xWFRqMWtqeVRxN1B6LVVqVFptek15SmNW emwxc0RHSTU1c2VxZDllVmZzJmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+SWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48 L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1l dmVudEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1XUHFJcG1kS2NkcEtaWHVwTWYteGli aTVPLXQwWnVScGxsQXpaSTZyZ2pRJmFtcDtzPTFYVGoxa2p5VHE3UHotVWpUWm16TXlKY1Z6bDFz REdJNTVzZXFkOWVWZnMmYW1wO2U9Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VH SnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1XUHFJcG1kS2NkcEtaWHVwTWYteGliaTVPLXQw WnVScGxsQXpaSTZyZ2pRJmFtcDtzPTFYVGoxa2p5VHE3UHotVWpUWm16TXlKY1Z6bDFzREdJNTVz ZXFkOWVWZnMmYW1wO2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1w O2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JL MTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7 bT1XUHFJcG1kS2NkcEtaWHVwTWYteGliaTVPLXQwWnVScGxsQXpaSTZyZ2pRJmFtcDtzPTFYVGox a2p5VHE3UHotVWpUWm16TXlKY1Z6bDFzREdJNTVzZXFkOWVWZnMmYW1wO2U9PC9hPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB05047D23D9A9853AB83C7067F5C60CY4PR21MB0504namp_-- From nobody Mon Jun 19 11:58:14 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF5131819 for ; Mon, 19 Jun 2017 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le61WdtyS2tK for ; Mon, 19 Jun 2017 11:58:06 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDE1131689 for ; Mon, 19 Jun 2017 11:58:05 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m62so1183991itc.0 for ; Mon, 19 Jun 2017 11:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jeH4twq0/TeecauemHKkMiGo5ORYovYpantWqxvqW+w=; b=Vej+d7O02SjNtnoqhsXVgCAyaWLQ/+RNw7Z2UtlSclcQ4RaQsozB7le0SE2uSdNVoB wT4ovnqWWNx2ndNfOO1CSUSetJG6j2qWlcw2rGtn+M1jV9GR5y1OIBZlGKX6CX21R1jz +kMsy/ACbEvDYEKx/Wc9HcqjBaqKEjrosCKlOTwEd7U1IfZEkl4knnhuI/SxYEeCpChp 4g41mLMFIZj4fmg4kRYifh+Nt1XKiY1t4KnVJoVS21Qke3dRnfPEy432nmFg09JpdWHm zYYQscXO+kooIOigGjsY0vnwmCDf97kPpBHY9omNkBksLDbegAsLGbtwOCuNw+epYHFQ 8kGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jeH4twq0/TeecauemHKkMiGo5ORYovYpantWqxvqW+w=; b=apIJN/3EAiv7pWG9IvLkkZE/QXSZ/hmCVXhOsMdSGoD9QR4GY9MLQE0i8xilsJSavI h/HQlJO+xISiYK7qDkQR/7VLdNJvY7xVStficSqU/2J5zBLZjhJU1GdJOx5rjBsLobQS TixQylm5zbhf87NGIfo8Inzo+PYNAoPVYygm6nslqU7mT3xm8Pgk0SRr5t9CRnQUZWFV M9zDuUmjMsmnxAv51Jj5i+PDVulLTfIo5C/BO/edetENzWWUwk6eWWWJTt4eBOoMt860 DRSA6RyU8FPLgq5CJO6OwpgOjT7PFHiu1uXd1CQY0Q71FwcwG+GnUH8QfLblDWOjveET K+Uw== X-Gm-Message-State: AKS2vOwwKNeQXk0fViV2jhANFV4I9kG/psrPz8vGWA5C3wvKak1ly0b+ sk/wuCrXCxvcJsHb3qH0h4MWW8lmJUfq X-Received: by 10.36.27.72 with SMTP id 69mr199078its.116.1497898684365; Mon, 19 Jun 2017 11:58:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.36 with HTTP; Mon, 19 Jun 2017 11:57:43 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> From: Marius Scurtescu Date: Mon, 19 Jun 2017 11:57:43 -0700 Message-ID: To: Mike Jones Cc: Yaron Sheffer , Justin Richer , "Richard Backman, Annabelle" , Henk Birkholz , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="001a114495b6fe5169055254b699" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:58:12 -0000 --001a114495b6fe5169055254b699 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones wrote: > I=E2=80=99m sorry to be slow replying to some messages in this thread. I= have a > lot of other things on my plate, but I will take the time now to reply, > because I wholeheartedly disagree with some of the statements below and > believe it would be severely harmful to the specification and its adoptio= n > to act upon them. Specifically: > > > > - I disagree that specific rules should be made for the =E2=80=9Csub= =E2=80=9D claim. > Claims usage needs to be up to the application. I know that many othe= rs > agree with me, because the OpenID Connect working group designed the l= ogout > token in http://openid.net/specs/openid-connect-backchannel-1_ > 0-04.html#LogoutToken (which is also used as an example in > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 > ) > to use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibiting= this usage would be > a completely unnecessary breaking change =E2=80=93 as it=E2=80=99s imp= ossible to confuse a > logout token with an ID Token, for reasons already cites in this threa= d. > > Solving the confusion is one problem. The other problem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top level iss is different from the iss of the sub, a top level sub is not possible. And I don't want to downplay the confusion problem either. I think it is a real concern and I think a solid solution is important. The OpenID Working Group designed logout tokens without secevent in mind. I agree we should not recklessly break compatibility, but to me it seems necessary in this case. > > - > > > > - (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 > = . > No further =E2=80=9Ciss=E2=80=9D rules are needed.) > > Further iss ruies are absolutely needed for the RP to IdP case described above. > > - > > > > - It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to = be used for some > profiles to differentiate between kinds of JWTs. Its use should not b= e > mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D > functionality by defining another claim with a duplicative meaning. > > If typ can be use and no other claim is needed, then let's talk about that. I do think SET should mandate it. I don't understand why not. Can you please propose with examples how can typ be used? > > - > > > > - I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of > JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D This reflects a > misunderstanding. It=E2=80=99s the **value** of the nonce that self-s= ecures > the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is presen= t. Any and all JWTs can > simultaneously use =E2=80=9Cnonce=E2=80=9D without any risk of conflic= t, since the nonce > value is a cryptographically secure random number. > > For SETs I cannot see how the nonce value is useful. That value is not passed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage of the JWT, a very weak solution to the confusion problem. > > - > > > > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d = be glad > to have in-person discussions about these topics there. > > > > -- Mike > > > > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or= any other claim) > or forcing it to be located in a non-standard location makes about as muc= h > sense as arbitrarily saying that, for a particular profile, the Latin wor= d > for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name in= stead of =E2=80=9Csub=E2=80=9D. > Yes, it will completely differentiate this profile from others not spelli= ng > the claim name this way, but it would certainly be an impediment to the u= se > of standard JWT libraries and to interoperability. > If we define that sub must be at the event level then it is at a standard location, I don't see what the issue is. The impediment you mention is the actual solution. I don't think that a JWT library that was written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case the event level iss+sub is not an issue at all. > > > *From:* Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > *Sent:* Saturday, June 17, 2017 1:45 PM > *To:* Justin Richer ; Marius Scurtescu < > mscurtescu@google.com> > *Cc:* Richard Backman, Annabelle ; Mike Jones < > Michael.Jones@microsoft.com>; Henk Birkholz de>; ID Events Mailing List ; Phil Hunt < > phil.hunt@oracle.com> > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id- > 2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > --001a114495b6fe5169055254b699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jun 17, 2017 at 2:06 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

I=E2=80=99m sorry to b= e slow replying to some messages in this thread.=C2=A0 I have a lot of othe= r things on my plate, but I will take the time now to reply, because I whol= eheartedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adop= tion to act upon them.=C2=A0 Specifically:

=C2=A0

Solving the confusion is one problem. The other problem= I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we= solving that problem Mike? In this case the top level iss is different fro= m the iss of the sub, a top level sub is not possible.

=
And I don't want to downplay the confusion problem either. I think= it is a real concern and I think a solid solution is important.
=
The OpenID Working Group designed logout tokens without sece= vent in mind. I agree we should not recklessly break compatibility, but to = me it seems necessary in this case.
=C2=A0

=C2=A0


Further iss ruies are absolut= ely needed for the RP to IdP case described above.

=C2=A0
  • =

=C2=A0

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used= for some profiles to differentiate between kinds of JWTs.=C2=A0 Its use sh= ould not be mandated in the SET spec.=C2=A0 I would oppose duplicating the = =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a duplic= ative meaning.
If typ can be use and= no other claim is needed, then let's talk about that. I do think SET s= hould mandate it. I don't understand why not. Can you please propose wi= th examples how can typ be used?

=C2=A0

    • =C2=A0

    • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other profile of JWT can ever use the "no= nce=E2=80=9D claim.=E2=80=9D=C2=A0 This reflects a misunderstanding.= =C2=A0 It=E2=80=99s the *value* of the nonce that self-secures the J= WT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is present.=C2=A0 Any and all JWTs can simultaneously use =E2=80=9Cn= once=E2=80=9D without any risk of conflict, since the nonce value is a cryp= tographically secure random number.
=
For SETs I cannot see how the nonce value is useful. That va= lue is not passed back and it cannot be verified. Only the presence of the = claim could have some use, hinting at the usage of the JWT, a very weak sol= ution to the confusion problem.
=C2=A0

=C2=A0

Will some of you be at= the Cloud Identity Summit next week?=C2=A0 I=E2=80=99d be glad to have in-= person discussions about these topics there.

=C2=A0

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

=C2=A0

P.S.=C2=A0 Food for th= ought:=C2=A0 Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any other cla= im) or forcing it to be located in a non-standard location makes about as m= uch sense as arbitrarily saying that, for a particular profile, the Latin word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the= claim name instead of =E2=80=9Csub=E2=80=9D.=C2=A0 Yes, it will completely= differentiate this profile from others not spelling the claim name this wa= y, but it would certainly be an impediment to the use of standard JWT libraries and to interoperability.


If we define that sub must be at the event level then it is= at a standard location, I don't see what the issue is. The impediment = you mention is the actual solution. I don't think that a JWT library th= at was written for Id Tokens should be used to parse SETs. The library has = to be SET aware, in which case the event level iss+sub is not an issue at a= ll.


=C2=A0

=C2=A0

From:= Yaron Sheffer [mailto:yaronf.ietf@gmail.= com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscu= rtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike = Jones <Michael.Jones@microsoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing Lis= t <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules f= or "sub" and "iss" that can be defined in the SET spec.=

Almost everybody agrees on a long-term "usage" claim ("ty= pe" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use = it in the SET document before it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <m= scurtescu@google.com> wrote:

=C2=A0

+1 to what Annabelle said.

=C2=A0

Also, Mike you are missing the other requirement, fo= r RPs to send events to an IdP. The iss+sub pair at the top level is broken= in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <= ;phil.hunt@oracle.com> wrote:

+1

=C2=A0

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.= com> wrote:

Mike,

=C2=A0

Your explanation for why this is a non-problem is de= pendent upon side effects of elements of OpenID Connect that were not desig= ned to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certa= in that a nonce-less ID Token is really an ID Token. Any party that the cal= ler passes the ID Token off to has no way to verify its provenance.<= u>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem = again.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim.=

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that = cares about disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and r= eplay attacks are both things that happen. What=E2=80=99s being proposed is= a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use commo= n libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library co= uld handle disambiguation for any JWT profile, whereas with the status quo = each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike J= ones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <= ;henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

You=E2=80=99ve heard o= f =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d characterize = the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2= =80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0

Mandatory solutions ar= e being proposed in this thread to problems that there=E2=80=99s no evidenc= e that we actually even have.=C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.h= tml.=C2=A0 If people have data showing that this is possible with speci= fic kinds of Access Tokens or other real JWT deployments, please provide sp= ecifics, so that we can use that data to inform appropriate engineering choices on our part.

=C2=A0

The proposed =E2=80=9C= solutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80=9D in= the normal way, or requiring a type claim, would make previously simple th= ings unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-bounces@= ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkho= lz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain w= hat you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better analogy wou= ld be the X.509 Key Usage extension: a multi-valued property that declares = the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to i= t in some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius= Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.d= e>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank" class= =3D"cremed">henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target clie= nt, but not the intended usage (access token to authorize resource access o= r SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.<= /p>

=C2=A0

I don't know what do you mean by "intend&qu= ot; (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Di= ck Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matak= e.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.co= m <mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gma= il.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" class=3D"cremed">adaw= es@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wro= te:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracl= e.com <mailto:phil.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:mscurtescu@google.com>> wrote:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-= event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxP= EivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6mi= RiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&a= mp;e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event= @ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org = <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |ad= awes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>= |+1= 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>

=C2=A0




_______________________________________________

Id-event mailing list


Id-event@ietf.org


https://www.ietf.org/mailman/listinfo/id-event=

=C2=A0


--001a114495b6fe5169055254b699-- From nobody Mon Jun 19 12:11:51 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8949B131809 for ; Mon, 19 Jun 2017 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzXdqFaNvKYA for ; Mon, 19 Jun 2017 12:11:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57281294B7 for ; Mon, 19 Jun 2017 12:11:44 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5JJBVuV005207 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jun 2017 19:11:31 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5JJBUsn017552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jun 2017 19:11:30 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5JJBTAt027357; Mon, 19 Jun 2017 19:11:29 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Jun 2017 12:11:28 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_258ED39A-506D-41D2-9810-9C7E713BA0A8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 19 Jun 2017 12:11:26 -0700 In-Reply-To: Cc: Mike Jones , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List To: Marius Scurtescu References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 19:11:51 -0000 --Apple-Mail=_258ED39A-506D-41D2-9810-9C7E713BA0A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Editor Hat] Just a side note. It would be good to get a resolution on this sometime = this week. Based on the consensus reached, I would like to update the = SET document next week in order to meet the publication timelines for = Prague. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 19, 2017, at 11:57 AM, Marius Scurtescu = wrote: >=20 > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones = > = wrote: > I=E2=80=99m sorry to be slow replying to some messages in this thread. = I have a lot of other things on my plate, but I will take the time now = to reply, because I wholeheartedly disagree with some of the statements = below and believe it would be severely harmful to the specification and = its adoption to act upon them. Specifically: >=20 > =20 >=20 > I disagree that specific rules should be made for the =E2=80=9Csub=E2=80= =9D claim. Claims usage needs to be up to the application. I know that = many others agree with me, because the OpenID Connect working group = designed the logout token = inhttp://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutTok= en = (which is also used as an = example in = https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 = ) to use the =E2=80=9Csub=E2=80=9D = claim in the normal way. Prohibiting this usage would be a completely = unnecessary breaking change =E2=80=93 as it=E2=80=99s impossible to = confuse a logout token with an ID Token, for reasons already cites in = this thread. > Solving the confusion is one problem. The other problem I keep = mentioning is SETs issued by an RP to be sent to an IdP. How are we = solving that problem Mike? In this case the top level iss is different = from the iss of the sub, a top level sub is not possible. >=20 > And I don't want to downplay the confusion problem either. I think it = is a real concern and I think a solid solution is important. >=20 > The OpenID Working Group designed logout tokens without secevent in = mind. I agree we should not recklessly break compatibility, but to me it = seems necessary in this case. > =20 > =20 >=20 > (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at = https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 = . No further =E2=80=9Ciss=E2=80=9D= rules are needed.) >=20 > Further iss ruies are absolutely needed for the RP to IdP case = described above. >=20 > =20 > =20 >=20 > It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be = used for some profiles to differentiate between kinds of JWTs. Its use = should not be mandated in the SET spec. I would oppose duplicating the = =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a = duplicative meaning. > If typ can be use and no other claim is needed, then let's talk about = that. I do think SET should mandate it. I don't understand why not. Can = you please propose with examples how can typ be used? >=20 > =20 > =20 >=20 > I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9C= No other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D = This reflects a misunderstanding. It=E2=80=99s the *value* of the = nonce that self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80= =9D claim is present. Any and all JWTs can simultaneously use = =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a cryptographically secure random number. >=20 > For SETs I cannot see how the nonce value is useful. That value is not = passed back and it cannot be verified. Only the presence of the claim = could have some use, hinting at the usage of the JWT, a very weak = solution to the confusion problem. > =20 > =20 >=20 > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d= be glad to have in-person discussions about these topics there. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D = (or any other claim) or forcing it to be located in a non-standard = location makes about as much sense as arbitrarily saying that, for a = particular profile, the Latin word for subject =E2=80=9Csubiectum=E2=80=9D= must be used as the claim name instead of =E2=80=9Csub=E2=80=9D. Yes, = it will completely differentiate this profile from others not spelling = the claim name this way, but it would certainly be an impediment to the = use of standard JWT libraries and to interoperability. >=20 >=20 > If we define that sub must be at the event level then it is at a = standard location, I don't see what the issue is. The impediment you = mention is the actual solution. I don't think that a JWT library that = was written for Id Tokens should be used to parse SETs. The library has = to be SET aware, in which case the event level iss+sub is not an issue = at all. >=20 >=20 > =20 >=20 > =C2=A0 <> > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com = ]=20 > Sent: Saturday, June 17, 2017 1:45 PM > To: Justin Richer >; Marius = Scurtescu > > Cc: Richard Backman, Annabelle >; Mike Jones >; Henk Birkholz = >; ID Events Mailing List = >; Phil Hunt = > >=20 >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > So to summarize what I'm seeing on this thread: >=20 > Everybody agrees with Marius's short-term solution, specific rules for = "sub" and "iss" that can be defined in the SET spec. >=20 > Almost everybody agrees on a long-term "usage" claim ("type" is taken) = that should be defined elsewhere, e.g. in the JWT BCP. >=20 > Did I miss anything? >=20 > By the way, if we do add a "usage" claim, we need to also use it in = the SET document before it is published. >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > On 15/06/17 22:08, Justin Richer wrote: >=20 > +1 to this as well.=20 >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: >=20 > =20 >=20 > +1 to what Annabelle said.=20 >=20 > =20 >=20 > Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >=20 >=20 >=20 > Marius >=20 > =20 >=20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: >=20 > +1 >=20 > =20 >=20 > Phil >=20 >=20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >=20 > Mike, >=20 > =20 >=20 > Your explanation for why this is a non-problem is dependent upon side = effects of elements of OpenID Connect that were not designed to solve = this issue. As a result, I see several issues with it: >=20 > 1. The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance. >=20 > 2. Any future ID Token distribution method needs to solve this = problem again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile = that cares about disambiguation has to invent its own solution to the = problem. >=20 > =20 >=20 > We know from experience that naming collisions and replay attacks are = both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. >=20 > =20 >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > =20 >=20 > =20 >=20 > From: Id-event > on behalf of Mike Jones = > > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > > Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematur= e pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >=20 > =20 >=20 > Mandatory solutions are being proposed in this thread to problems that = there=E2=80=99s no evidence that we actually even have. It=E2=80=99s = already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >=20 > =20 >=20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use = of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, = would make previously simple things unnecessarily complex. Yes, then = the result is then different than a normal JWT but a consequence of this = is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu >; Henk Birkholz = > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > Echoing Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D? >=20 > =20 >=20 > To your first question, I think a better analogy would be the X.509 = Key Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context. >=20 > =20 >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > =20 >=20 > =20 >=20 > From: Id-event > on behalf of Marius Scurtescu = > > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >=20 > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"? >=20 > =20 >=20 > "aud" (audience) specifies the target client, but not the intended = usage (access token to authorize resource access or SET to communicate a = security event?) >=20 > =20 >=20 > "scope" is not used by SET. >=20 > =20 >=20 > I don't know what do you mean by "intend" (or intent)? >=20 > =20 >=20 > =20 >=20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >=20 > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event > on behalf of Dick Hardt = > > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > > *Cc: *Adam Dawes >, = "matake, nov" >, ID Events Mailing = List >, "Phil Hunt (IDM)" = > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be = in 3.9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = = >> wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > >> = wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 = >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > >> wrote: >=20 > I was initially a fan of keeping SETS to be very similar = to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > >> wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > = >>: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > >> wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens = in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: = the > SET issuer in some cases must be different from = the > "sub" issuer. This is the case of an RP sending = SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the = event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be = different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please = note > "should" and not "must" > > > > This solution also allows different profiles = that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not = solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I = think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list >=20 > > Id-event@ietf.org = > > > > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com = > > |+1 = 650-214-2410 > > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Subscribe to the HARDTWARE > mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = > =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DF4o5yq8KJK6Tchr= Rbj43SITOywEvWvZ-FKc1IbHpuV8&s=3DxyQQ7D6EchoHthYPpTNHzy4vYat2_FkHJ0tBj1ldL= RI&e=3D = --Apple-Mail=_258ED39A-506D-41D2-9810-9C7E713BA0A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Editor Hat]
Just a side note. It would be = good to get a resolution on this sometime this week. Based on the = consensus reached, I would like to update the SET document next week in = order to meet the publication timelines for Prague.

Phil

Oracle = Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 19, 2017, at 11:57 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Sat, = Jun 17, 2017 at 2:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m sorry to be slow replying to some messages in = this thread.  I have a lot of other things on my plate, but I will = take the time now to reply, because I wholeheartedly disagree with some = of the statements below and believe it would be severely harmful to the = specification and its adoption to act upon them.  Specifically:

 

  • I disagree that = specific rules should be made for the =E2=80=9Csub=E2=80=9D claim.  = Claims usage needs to be up to the application.  I know that many = others agree with me, because the OpenID Connect working group designed = the logout token inhttp://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken (which is also used as an = example in https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2) = to use the =E2=80=9Csub=E2=80=9D claim in the normal way.  = Prohibiting this usage would be a completely unnecessary breaking change = =E2=80=93 as it=E2=80=99s impossible to confuse a logout token with an = ID Token, for reasons already cites in this = thread.
Solving the = confusion is one problem. The other problem I keep mentioning is SETs = issued by an RP to be sent to an IdP. How are we solving that problem = Mike? In this case the top level iss is different from the iss of the = sub, a top level sub is not possible.

And I don't want to downplay the = confusion problem either. I think it is a real concern and I think a = solid solution is important.

The OpenID Working Group designed = logout tokens without secevent in mind. I agree we should not recklessly = break compatibility, but to me it seems necessary in this = case.
 

 


Further iss ruies are absolutely needed = for the RP to IdP case described above.

 

 

  • It=E2=80=99s fine for = the =E2=80=9Ctyp=E2=80=9D header parameter to be used for some profiles = to differentiate between kinds of JWTs.  Its use should not be = mandated in the SET spec.  I would oppose duplicating the =E2=80=9Cty= p=E2=80=9D functionality by defining another claim with a duplicative = meaning.
If typ can be = use and no other claim is needed, then let's talk about that. I do think = SET should mandate it. I don't understand why not. Can you please = propose with examples how can typ be used?

 

 

  • I=E2=80=99ll also = respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other profile of JWT can ever use the "nonce=E2=80=9D = claim.=E2=80=9D  This reflects a misunderstanding.  = It=E2=80=99s the *value* of the nonce that = self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D = claim is present.  Any and all JWTs can simultaneously use = =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a cryptographically secure random = number.

For SETs I cannot see how the nonce = value is useful. That value is not passed back and it cannot be = verified. Only the presence of the claim could have some use, hinting at = the usage of the JWT, a very weak solution to the confusion = problem.
 

 

Will some of you be at the Cloud Identity = Summit next week?  I=E2=80=99d be glad to have in-person = discussions about these topics there.

 

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

 

P.S.  Food for thought:  = Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any other claim) or = forcing it to be located in a non-standard location makes about as much = sense as arbitrarily saying that, for a particular profile, the Latin = word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim = name instead of =E2=80=9Csub=E2=80=9D.  Yes, it will completely = differentiate this profile from others not spelling the claim name this = way, but it would certainly be an impediment to the use of standard JWT = libraries and to = interoperability.


If we define that sub must be at the = event level then it is at a standard location, I don't see what the = issue is. The impediment you mention is the actual solution. I don't = think that a JWT library that was written for Id Tokens should be used = to parse SETs. The library has to be SET aware, in which case the event = level iss+sub is not an issue at all.


 

 

From: Yaron = Sheffer [mailto:yaronf.ietf@gmail.com] 
Sent: Saturday, June 17, 2017 = 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscurtescu@google.com>
Cc: Richard Backman, Annabelle = <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; Henk Birkholz = <henk.birkholz@sit.fraunhofer.de>; = ID Events Mailing List <id-event@ietf.org>; Phil Hunt = <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for = Id/Access Token confusion and distinct SET issuer

 

So to summarize what I'm seeing on this = thread:

Everybody = agrees with Marius's short-term solution, specific rules for "sub" and = "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term = "usage" claim ("type" is taken) that should be defined elsewhere, e.g. = in the JWT BCP.

Did = I miss anything?

By = the way, if we do add a "usage" claim, we need to also use it in the SET = document before it is published.

Thanks,

    Yaron

 

On 15/06/17 = 22:08, Justin Richer wrote:

+1 to this as = well. 

 

 =E2=80= =94 Justin

 

On Jun 15, 2017, at = 1:09 PM, Marius Scurtescu <mscurtescu@google.com> = wrote:

 

+1 to what Annabelle = said. 

 

Also, = Mike you are missing the other requirement, for RPs to send events to an = IdP. The iss+sub pair at the top level is broken in this case.


Marius

 

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

+1

 

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

Mike,

 

Your explanation for why this is a non-problem is = dependent upon side effects of elements of OpenID Connect that were not = designed to solve this issue. As a result, I see several issues with = it:

1.       The caller of the = Token Endpoint is the only party that can be certain that a nonce-less = ID Token is really an ID Token. Any party that the caller passes the ID = Token off to has no way to verify its provenance.

2.       Any future ID Token = distribution method needs to solve this problem again.

3.      No other profile of = JWT can ever use the "nonce=E2=80=9D claim.

4.      This is only a = solution for ID Tokens. Every other JWT profile that cares about = disambiguation has to invent its own solution to the problem.

 

We know from = experience that naming collisions and replay attacks are both things = that happen. What=E2=80=99s being proposed is a simple, defensive = measure against these risks. You brought up JWT libraries: a general = solution actually makes it easier to use common libraries for JWT = parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic.

 

-- 

Annabelle = Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike = Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, = 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, = Annabelle" <richanna@amazon.com>, ID Events Mailing List = <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer

 

You=E2=80=99ve heard of = =E2=80=9Cpremature optimization=E2=80=9D.  I=E2=80=99d characterize = the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D = =E2=80=93 making things that can and should be simple complex, without = data showing there=E2=80=99s any need to do so.

 

Mandatory solutions are being proposed in this = thread to problems that there=E2=80=99s no evidence that we actually = even have.  It=E2=80=99s already been established that it=E2=80=99s = impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part.

 

The proposed = =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2= =80=9D in the normal way, or requiring a type claim, would make = previously simple things unnecessarily complex.  Yes, then the = result is then different than a normal JWT but a consequence of this is = that custom parsing code would have to be used, rather than a standard = JWT parser.  The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures.  = Keeping it simple is the key to adoption.  Standards are only = useful if they are actually used.

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, = Annabelle
Sent: Tuesday, June 13, 2017 5:33 = PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List = <id-event@ietf.org>
Subject: Re: [Id-event] solution for = Id/Access Token confusion and distinct SET issuer

 

Echoing = Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D?

 

To your first question, I think a better analogy = would be the X.509 Key Usage extension: a multi-valued property that = declares the intended purpose of the JWT, and that a recipient may refer = to when determining whether to accept a JWT being presented to it in = some context.

 

-- 

Annabelle Richard Backman

Identity = Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 = at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List = <id-event@ietf.org>
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer

 

On Tue, Jun 13, 2017 = at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> = wrote:

And a 2nd = question.

What semantics would "usage" = provide that that are not covered via "intend", "audience", and = "scope"?

 

"aud" = (audience) specifies the target client, but not the intended usage = (access token to authorize resource access or SET to communicate a = security event?)

 

"scope" = is not used by SET.

 

I don't = know what do you mean by "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this = together!

I think the assumptions inherent = in 3.9 are flawed:

=C2=B7We can=E2=80=99t = guarantee that every type of JWT will have a mutually exclusive set of = valid claims and/or header parameters, and enforcing this requires a = =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that = JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a = current spec.

=C2=B7It is unrealistic to = expect implementers to adhere to the =E2=80=9Cdifferent keys for = different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec or = not, implementers will ignore this because managing one key is easier = than managing N different keys.

=C2=B7Ditto = for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusag= e=E2=80=9D claim/header parameter.

-- 

Annabelle Richard Backman

Identity= Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick = Hardt <dick.hardt@gmail.com>
*Date: = *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu = <mscurtescu@google.com>
*Cc: *Adam = Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: = *Re: [Id-event] solution for Id/Access Token confusion and distinct SET = issuer

Agreed. Note that there is still = lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.com>> = wrote:

    Thanks for the pointer = Dick, very good timing :-)

  =   The issue is = described by "2.7. Cross-JWT Confusion" and the
  =   mitigation is = in "3.9. Use Mutually Exclusive Validation Rules for
  =   Different Kinds = of JWTs", specifically "Use different sets of
  =   required = claims...", "Use different keys for different kinds of
    JWTs." and "Use different = issuers for different kinds of JWTs.".

 =   I still think = that a "type" claim would bring a lot of clarity and
  =   safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 = PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:
        Yaron, Mike and I just = published an BCP ID for JWT
      =   http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 = PM Adam Dawes <adawes@google.com
    =     <mailto:adawes@google.com>> wrote:

            I was initially a fan of = keeping SETS to be very similar to
      =       id = tokens but I now think this is a better plan.

            On Thu, Jun 8, 2017 at 6:56 = PM matake, nov <nov@matake.jp
      =       <mailto:nov@matake.jp>> wrote:

                +1 especially for "type"

            =     2017-06-09= 10:32 GMT+09:00 Phil Hunt (IDM)
      =           <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>:

            =         +1

                =     Phil


        =              > On Jun 8, 2017, at = 6:28 PM, Marius Scurtescu
        =             <mscurtescu@google.com

              =       <mailto:mscurtescu@google.com>> = wrote:
              =        >
      =                > There were a = couple of proposals on how to
        =             distinguish SETs from Id = Tokens and Access Tokens in
        =             such a way that naive = implementations will not
        =             confuse one for the other = and open up security
          =           vulnerabilities.
                =      >
        =              > There is also = another important requirement: the
      =               SET issuer in some cases = must be different from the
        =             "sub" issuer. This is the = case of an RP sending SETs
        =             to an IdP.
                =      >
        =              > With these = requirements in mind I propose the
      =               following:
                =      > - both "sub" and "iss" to be defined at the = event
              =       level
  =                   =  > - "iss" at event level and at top SET level can
                =     be = different
              =        > - "iss" and "sub" at event level can be = different
              =       across events in the same = SET
              =        > - "sub" should NOT be present at the top = SET
              =       level (this solves the = disambiguation), please note
        =             "should" and not "must"
                =      >
        =              > This solution also = allows different profiles that
        =             define event types to = define additional claims
        =             related to sub (like email = or phone_number) and
          =           since all these claims will = be at the event level
          =           there will be no collisions = or ambiguity.
            =          >
    =                  > = Another proposal (which I supported) was to
    =                 define a composite "aud" = claim. This is not solving
        =             the requirement for a = distinct  SET issuer. Also,
      =               having the same claim name = having different syntax
          =           in different token types = could lead to confusion.
        =              >
  =                   =  > And yet another proposal was to introduce a new
                =     claim = for JWTs that defines a "type". This is not
    =                 practical in the short = term, and it also is not
        =             solving the distinct issuer = requirement, but I think
        =             this is something the JWT = group should seriously
          =           consider.
                =      >
        =              > Thoughts?
                =      >
        =              > Marius

            =          > = _______________________________________________
                =      > Id-event mailing list

            =          > Id-event@ietf.org <mailto:Id-event@ietf.org>
    =                  >
                =     https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

  =                   _____________________________= __________________
      =               Id-event mailing list
                =     Id-event@ietf.org <mailto:Id-event@ietf.org>
    =                 https://www.ietf.org/mailman/listinfo/id-event

  =               _____________________________= __________________
      =           Id-event mailing list
                Id-event@ietf.org <mailto:Id-event@ietf.org>
    =             https://www.ietf.org/mailman/listinfo/id-event

  =           -- 
  =           Adam Dawes | Sr. Product = Manager |adawes@google.com
    =         <mailto:adawes@google.com> |+1 = 650-214-2410
          =   <tel:(650)%20214-2410>

            _____________________________= __________________
      =       Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
    =         https://www.ietf.org/mailman/listinfo/id-event

  =       -- 
  =       Subscribe to the HARDTWARE = <http://hardtware.com/> mail list to
        learn about projects I am = working on!



-- 

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about = projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 




_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DF4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=3DxyQQ7D6Ech= oHthYPpTNHzy4vYat2_FkHJ0tBj1ldLRI&e=3D
= --Apple-Mail=_258ED39A-506D-41D2-9810-9C7E713BA0A8-- From nobody Mon Jun 19 14:27:23 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F431293EC for ; Mon, 19 Jun 2017 14:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WzC0Ivtxqki for ; Mon, 19 Jun 2017 14:27:15 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0114.outbound.protection.outlook.com [104.47.32.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE311293D6 for ; Mon, 19 Jun 2017 14:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wXSdGk5yb0dQGFsrTMq7vUdAQJjL6OaJP+Zl5AMU34c=; b=WV1+JCVa9CMyEHlHwQqdl74ZQ6J65S6+dH6iNq3oRCq8PpvGyRkuQ+TlWpsyodJxbCMcmj0QfUtONiFXLCOAUZjw86RIeGouBShpzudZU38LCAt5UhzDeHyZeOHyLVps86rCkVtDiIcr2gY590fqYyC/Eo9mn33Pphd71sFmbYY= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0150.namprd21.prod.outlook.com (10.173.189.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Mon, 19 Jun 2017 21:27:11 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.000; Mon, 19 Jun 2017 21:27:11 +0000 From: Mike Jones To: Marius Scurtescu CC: Yaron Sheffer , Justin Richer , "Richard Backman, Annabelle" , Henk Birkholz , ID Events Mailing List , Phil Hunt Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAAAQ5CAAwZmgIAAKJzw Date: Mon, 19 Jun 2017 21:27:10 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-19T14:27:08.0471284-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [40.135.196.198] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0150; 7:gB/AbWepHJ7P/ifCH4RSJ/mW8kyOkse57C8lsglDtfpcgXaSTPkh7+wdR+6Aja7kgjxqVS4InrAAa/38dAuxnCkwH3yfcYQcacdmYGd0AB49PDReMVVdJBHDSoKCUVY3m49IF7Fs2PiVXwM2vxO3s+4As+YIjU8lFoMHOhc5yDQCo4AJUnB8QptPsIvC0UGkLMcVHiBfMcENbk+qeYfsbDInDodZeLsferVXwNgY5wfR1LWAQXRS918H7vaZDeCOrW9NI7yiFR/TDEPfg3TYTggPAflt4ifzlcrCI5IoNAhATbRXn0h1AjiOhRzcKk8XeWQlAYQ7pWJ34b3YHg1C8xoOc43gjTrEGQYDMUoVo+PSEtI3ZX8FjcWmpGjofv94D+vrJqE+HEEZksCEPAP88PMtiyzkcMwFb/mlWDNDGGpNIEMagvJ+ZZWtyxNi8x3WwgUx9qDlC6jG5Bwd5l80nhoPBgyLrJSgj/roulE271gBZApQJABR3cZ+VapdOVsHZ3wNJwZ6MfZaz7w9pg5Ozs3zfrRI7aoOJ4rd1Uav+eJvGft4VMS0YsNgqymrIgb2G4XiAbUVnn2E1GTzwS20KIYtF7fx94kMqdLJ+YW06a07p99J5dhoiKoNP2ooGPWIF1ICmCee/WIlIPtYk/XTqh9PEOJJQInThc+PMvGK/B17gOeZTiweas6Q814HEUoyGdzjL+9SZglC+784A2j8dBJmmyPimJODnw9qLDwzP6K/2PZgSuAmXfy7SIK4AxTDeTDnL//cTu1e++LiaHSMRIEebj7SSY7eLUz9NP6QhOIhZVt0XNya626SETq5xafY x-ms-office365-filtering-correlation-id: 44bafd49-bdaf-4b8a-f5c4-08d4b759f24b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(48565401081)(300000503041)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:CY4PR21MB0150; x-ms-traffictypediagnostic: CY4PR21MB0150: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(131327999870524)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(47284530071512)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0150; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0150; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39450400003)(39840400002)(39410400002)(39860400002)(39400400002)(209900001)(24454002)(51914003)(377424004)(377454003)(7696004)(55016002)(229853002)(54896002)(53936002)(5660300001)(50986999)(99286003)(8990500004)(33656002)(54356999)(6916009)(38730400002)(2950100002)(53376002)(110136004)(16200700003)(6246003)(53946003)(6306002)(66066001)(54906002)(6436002)(93886004)(19609705001)(790700001)(25786009)(53546009)(102836003)(6116002)(10290500003)(606005)(2900100001)(3846002)(10090500001)(4326008)(5005710100001)(6506006)(14454004)(86612001)(72206003)(575784001)(86362001)(76176999)(236005)(74316002)(39060400002)(189998001)(9686003)(478600001)(7906003)(966005)(2906002)(3280700002)(3660700001)(8676002)(77096006)(81166006)(8936002)(7736002)(561944003)(122556002)(559001)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0150; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504CD98555BB5CEF0182DFAF5C40CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 21:27:10.9713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0150 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 21:27:20 -0000 --_000_CY4PR21MB0504CD98555BB5CEF0182DFAF5C40CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaXVzLCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGluZyB5b3UgKG9yIHRoZSBSSVNDIHdvcmtp bmcgZ3JvdXAgb3Igb3RoZXIgcHJvZmlsZXMpIGZyb20gZGVmaW5pbmcgZXZlbnRzIHRoYXQgY2Fu IGJlIHNlbnQgZnJvbSBSUHMgdG8gSWRQcyBub3csIHdpdGhvdXQgYW55IGNoYW5nZXMgdG8gdGhl IFNFVCBzcGVjLiAgU3BlY2lmeSB0aGUgY2xhaW1zIHlvdSB3YW50IHRvIHVzZSwgYW5kIHlvdeKA mXJlIGdvbGRlbi4NCg0KQnV0IGl0IHdvdWxkIGJlIGNvdW50ZXJwcm9kdWN0aXZlIHRvIHJlcXVp cmUgYWxsIG90aGVyIFNFVHMgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIHlvdXIgc3BlY2lm aWMgcHJvZmlsZS4gIFRoZXJlIGFyZSBzaW1wbGVyIHVzZSBjYXNlcyB0aGF0IGNhbiB1c2UgY2xh aW1zIGluIHNpbXBsZXIgd2F5cy4gIFRyeWluZyB0byBtYWtlIHRoZSBzaW1wbGUgdXNlIGNhc2Vz IGJlIGNvbXBsZXggd2lsbCBoYXZlIHRoZSBzaWRlIGVmZmVjdCBvZiBsaW1pdGluZyB0aGUgYWRv cHRpb24gb2YgdGhlIHNwZWMsIHdoaWNoIHdvdWxkbuKAmXQgYmUgZ29vZCBmb3IgYW55b25lLg0K DQpJZiBzdWNjZXNzZnVsLCBTRVRzIHdpbGwgaGF2ZSBtYW55IGRpZmZlcmVudCBwcm9maWxlcy4g IFRoYXTigJlzIGEgc2lnbiBvZiBzdWNjZXNzIOKAkyBub3QgYSBzaWduIG9mIHdlYWtuZXNzLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDE5LCAyMDE3IDExOjU4IEFNDQpUbzogTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlh cm9uZi5pZXRmQGdtYWlsLmNvbT47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IFJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPjsgSGVuayBCaXJr aG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT47IElEIEV2ZW50cyBNYWlsaW5n IExpc3QgPGlkLWV2ZW50QGlldGYub3JnPjsgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNv bT4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4g Y29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCk9uIFNhdCwgSnVuIDE3LCAyMDE3 IGF0IDI6MDYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJ4oCZbSBzb3JyeSB0byBi ZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUgbWVzc2FnZXMgaW4gdGhpcyB0aHJlYWQuICBJIGhhdmUg YSBsb3Qgb2Ygb3RoZXIgdGhpbmdzIG9uIG15IHBsYXRlLCBidXQgSSB3aWxsIHRha2UgdGhlIHRp bWUgbm93IHRvIHJlcGx5LCBiZWNhdXNlIEkgd2hvbGVoZWFydGVkbHkgZGlzYWdyZWUgd2l0aCBz b21lIG9mIHRoZSBzdGF0ZW1lbnRzIGJlbG93IGFuZCBiZWxpZXZlIGl0IHdvdWxkIGJlIHNldmVy ZWx5IGhhcm1mdWwgdG8gdGhlIHNwZWNpZmljYXRpb24gYW5kIGl0cyBhZG9wdGlvbiB0byBhY3Qg dXBvbiB0aGVtLiAgU3BlY2lmaWNhbGx5Og0KDQoNCiAgKiAgIEkgZGlzYWdyZWUgdGhhdCBzcGVj aWZpYyBydWxlcyBzaG91bGQgYmUgbWFkZSBmb3IgdGhlIOKAnHN1YuKAnSBjbGFpbS4gIENsYWlt cyB1c2FnZSBuZWVkcyB0byBiZSB1cCB0byB0aGUgYXBwbGljYXRpb24uICBJIGtub3cgdGhhdCBt YW55IG90aGVycyBhZ3JlZSB3aXRoIG1lLCBiZWNhdXNlIHRoZSBPcGVuSUQgQ29ubmVjdCB3b3Jr aW5nIGdyb3VwIGRlc2lnbmVkIHRoZSBsb2dvdXQgdG9rZW4gaW4gaHR0cDovL29wZW5pZC5uZXQv c3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFja2NoYW5uZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9rZW4g KHdoaWNoIGlzIGFsc28gdXNlZCBhcyBhbiBleGFtcGxlIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMikgdG8gdXNlIHRo ZSDigJxzdWLigJ0gY2xhaW0gaW4gdGhlIG5vcm1hbCB3YXkuICBQcm9oaWJpdGluZyB0aGlzIHVz YWdlIHdvdWxkIGJlIGEgY29tcGxldGVseSB1bm5lY2Vzc2FyeSBicmVha2luZyBjaGFuZ2Ug4oCT IGFzIGl04oCZcyBpbXBvc3NpYmxlIHRvIGNvbmZ1c2UgYSBsb2dvdXQgdG9rZW4gd2l0aCBhbiBJ RCBUb2tlbiwgZm9yIHJlYXNvbnMgYWxyZWFkeSBjaXRlcyBpbiB0aGlzIHRocmVhZC4NClNvbHZp bmcgdGhlIGNvbmZ1c2lvbiBpcyBvbmUgcHJvYmxlbS4gVGhlIG90aGVyIHByb2JsZW0gSSBrZWVw IG1lbnRpb25pbmcgaXMgU0VUcyBpc3N1ZWQgYnkgYW4gUlAgdG8gYmUgc2VudCB0byBhbiBJZFAu IEhvdyBhcmUgd2Ugc29sdmluZyB0aGF0IHByb2JsZW0gTWlrZT8gSW4gdGhpcyBjYXNlIHRoZSB0 b3AgbGV2ZWwgaXNzIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBpc3Mgb2YgdGhlIHN1YiwgYSB0b3Ag bGV2ZWwgc3ViIGlzIG5vdCBwb3NzaWJsZS4NCg0KQW5kIEkgZG9uJ3Qgd2FudCB0byBkb3ducGxh eSB0aGUgY29uZnVzaW9uIHByb2JsZW0gZWl0aGVyLiBJIHRoaW5rIGl0IGlzIGEgcmVhbCBjb25j ZXJuIGFuZCBJIHRoaW5rIGEgc29saWQgc29sdXRpb24gaXMgaW1wb3J0YW50Lg0KDQpUaGUgT3Bl bklEIFdvcmtpbmcgR3JvdXAgZGVzaWduZWQgbG9nb3V0IHRva2VucyB3aXRob3V0IHNlY2V2ZW50 IGluIG1pbmQuIEkgYWdyZWUgd2Ugc2hvdWxkIG5vdCByZWNrbGVzc2x5IGJyZWFrIGNvbXBhdGli aWxpdHksIGJ1dCB0byBtZSBpdCBzZWVtcyBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlLg0KDQoNCiAg Kg0KDQoNCiAgKiAgIChJIGFncmVlIHdpdGggdGhlIOKAnGlzc+KAnSBydWxlcyBhbHJlYWR5IGlu IHBsYWNlIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50 LXRva2VuLTAxI3NlY3Rpb24tMi4xLiAgTm8gZnVydGhlciDigJxpc3PigJ0gcnVsZXMgYXJlIG5l ZWRlZC4pDQoNCkZ1cnRoZXIgaXNzIHJ1aWVzIGFyZSBhYnNvbHV0ZWx5IG5lZWRlZCBmb3IgdGhl IFJQIHRvIElkUCBjYXNlIGRlc2NyaWJlZCBhYm92ZS4NCg0KDQoNCiAgKg0KDQoNCiAgKiAgIEl0 4oCZcyBmaW5lIGZvciB0aGUg4oCcdHlw4oCdIGhlYWRlciBwYXJhbWV0ZXIgdG8gYmUgdXNlZCBm b3Igc29tZSBwcm9maWxlcyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4ga2luZHMgb2YgSldUcy4g IEl0cyB1c2Ugc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBpbiB0aGUgU0VUIHNwZWMuICBJIHdvdWxk IG9wcG9zZSBkdXBsaWNhdGluZyB0aGUg4oCcdHlw4oCdIGZ1bmN0aW9uYWxpdHkgYnkgZGVmaW5p bmcgYW5vdGhlciBjbGFpbSB3aXRoIGEgZHVwbGljYXRpdmUgbWVhbmluZy4NCklmIHR5cCBjYW4g YmUgdXNlIGFuZCBubyBvdGhlciBjbGFpbSBpcyBuZWVkZWQsIHRoZW4gbGV0J3MgdGFsayBhYm91 dCB0aGF0LiBJIGRvIHRoaW5rIFNFVCBzaG91bGQgbWFuZGF0ZSBpdC4gSSBkb24ndCB1bmRlcnN0 YW5kIHdoeSBub3QuIENhbiB5b3UgcGxlYXNlIHByb3Bvc2Ugd2l0aCBleGFtcGxlcyBob3cgY2Fu IHR5cCBiZSB1c2VkPw0KDQoNCg0KICAqDQoNCg0KICAqICAgSeKAmWxsIGFsc28gcmVzcG9uZCB0 byBBbm5hYmVsbGXigJlzIGFzc2VydGlvbiB0aGF0IOKAnE5vIG90aGVyIHByb2ZpbGUgb2YgSldU IGNhbiBldmVyIHVzZSB0aGUgIm5vbmNl4oCdIGNsYWltLuKAnSAgVGhpcyByZWZsZWN0cyBhIG1p c3VuZGVyc3RhbmRpbmcuICBJdOKAmXMgdGhlICp2YWx1ZSogb2YgdGhlIG5vbmNlIHRoYXQgc2Vs Zi1zZWN1cmVzIHRoZSBKV1Qg4oCTIG5vdCB0aGF0IGFueSDigJxub25jZeKAnSBjbGFpbSBpcyBw cmVzZW50LiAgQW55IGFuZCBhbGwgSldUcyBjYW4gc2ltdWx0YW5lb3VzbHkgdXNlIOKAnG5vbmNl 4oCdIHdpdGhvdXQgYW55IHJpc2sgb2YgY29uZmxpY3QsIHNpbmNlIHRoZSBub25jZSB2YWx1ZSBp cyBhIGNyeXB0b2dyYXBoaWNhbGx5IHNlY3VyZSByYW5kb20gbnVtYmVyLg0KDQpGb3IgU0VUcyBJ IGNhbm5vdCBzZWUgaG93IHRoZSBub25jZSB2YWx1ZSBpcyB1c2VmdWwuIFRoYXQgdmFsdWUgaXMg bm90IHBhc3NlZCBiYWNrIGFuZCBpdCBjYW5ub3QgYmUgdmVyaWZpZWQuIE9ubHkgdGhlIHByZXNl bmNlIG9mIHRoZSBjbGFpbSBjb3VsZCBoYXZlIHNvbWUgdXNlLCBoaW50aW5nIGF0IHRoZSB1c2Fn ZSBvZiB0aGUgSldULCBhIHZlcnkgd2VhayBzb2x1dGlvbiB0byB0aGUgY29uZnVzaW9uIHByb2Js ZW0uDQoNCg0KICAqDQoNCldpbGwgc29tZSBvZiB5b3UgYmUgYXQgdGhlIENsb3VkIElkZW50aXR5 IFN1bW1pdCBuZXh0IHdlZWs/ICBJ4oCZZCBiZSBnbGFkIHRvIGhhdmUgaW4tcGVyc29uIGRpc2N1 c3Npb25zIGFib3V0IHRoZXNlIHRvcGljcyB0aGVyZS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgRm9vZCBm b3IgdGhvdWdodDogIFByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIChvciBhbnkgb3Ro ZXIgY2xhaW0pIG9yIGZvcmNpbmcgaXQgdG8gYmUgbG9jYXRlZCBpbiBhIG5vbi1zdGFuZGFyZCBs b2NhdGlvbiBtYWtlcyBhYm91dCBhcyBtdWNoIHNlbnNlIGFzIGFyYml0cmFyaWx5IHNheWluZyB0 aGF0LCBmb3IgYSBwYXJ0aWN1bGFyIHByb2ZpbGUsIHRoZSBMYXRpbiB3b3JkIGZvciBzdWJqZWN0 IOKAnHN1YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5hbWUgaW5zdGVhZCBv ZiDigJxzdWLigJ0uICBZZXMsIGl0IHdpbGwgY29tcGxldGVseSBkaWZmZXJlbnRpYXRlIHRoaXMg cHJvZmlsZSBmcm9tIG90aGVycyBub3Qgc3BlbGxpbmcgdGhlIGNsYWltIG5hbWUgdGhpcyB3YXks IGJ1dCBpdCB3b3VsZCBjZXJ0YWlubHkgYmUgYW4gaW1wZWRpbWVudCB0byB0aGUgdXNlIG9mIHN0 YW5kYXJkIEpXVCBsaWJyYXJpZXMgYW5kIHRvIGludGVyb3BlcmFiaWxpdHkuDQoNCklmIHdlIGRl ZmluZSB0aGF0IHN1YiBtdXN0IGJlIGF0IHRoZSBldmVudCBsZXZlbCB0aGVuIGl0IGlzIGF0IGEg c3RhbmRhcmQgbG9jYXRpb24sIEkgZG9uJ3Qgc2VlIHdoYXQgdGhlIGlzc3VlIGlzLiBUaGUgaW1w ZWRpbWVudCB5b3UgbWVudGlvbiBpcyB0aGUgYWN0dWFsIHNvbHV0aW9uLiBJIGRvbid0IHRoaW5r IHRoYXQgYSBKV1QgbGlicmFyeSB0aGF0IHdhcyB3cml0dGVuIGZvciBJZCBUb2tlbnMgc2hvdWxk IGJlIHVzZWQgdG8gcGFyc2UgU0VUcy4gVGhlIGxpYnJhcnkgaGFzIHRvIGJlIFNFVCBhd2FyZSwg aW4gd2hpY2ggY2FzZSB0aGUgZXZlbnQgbGV2ZWwgaXNzK3N1YiBpcyBub3QgYW4gaXNzdWUgYXQg YWxsLg0KDQoNCg0KDQpGcm9tOiBZYXJvbiBTaGVmZmVyIFttYWlsdG86eWFyb25mLmlldGZAZ21h aWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+XQ0KU2VudDogU2F0dXJkYXksIEp1 bmUgMTcsIDIwMTcgMTo0NSBQTQ0KVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxt YWlsdG86anJpY2hlckBtaXQuZWR1Pj47IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29v Z2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkNjOiBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9u LmNvbT4+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl Pj47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1l dmVudEBpZXRmLm9yZz4+OyBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9u IGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoN Cg0KU28gdG8gc3VtbWFyaXplIHdoYXQgSSdtIHNlZWluZyBvbiB0aGlzIHRocmVhZDoNCg0KRXZl cnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmlj IHJ1bGVzIGZvciAic3ViIiBhbmQgImlzcyIgdGhhdCBjYW4gYmUgZGVmaW5lZCBpbiB0aGUgU0VU IHNwZWMuDQoNCkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICJ1c2FnZSIg Y2xhaW0gKCJ0eXBlIiBpcyB0YWtlbikgdGhhdCBzaG91bGQgYmUgZGVmaW5lZCBlbHNld2hlcmUs IGUuZy4gaW4gdGhlIEpXVCBCQ1AuDQoNCkRpZCBJIG1pc3MgYW55dGhpbmc/DQoNCkJ5IHRoZSB3 YXksIGlmIHdlIGRvIGFkZCBhICJ1c2FnZSIgY2xhaW0sIHdlIG5lZWQgdG8gYWxzbyB1c2UgaXQg aW4gdGhlIFNFVCBkb2N1bWVudCBiZWZvcmUgaXQgaXMgcHVibGlzaGVkLg0KDQpUaGFua3MsDQoN CiAgICBZYXJvbg0KDQpPbiAxNS8wNi8xNyAyMjowOCwgSnVzdGluIFJpY2hlciB3cm90ZToNCisx IHRvIHRoaXMgYXMgd2VsbC4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSnVuIDE1LCAyMDE3LCBhdCAx OjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQorMSB0byB3aGF0IEFubmFiZWxsZSBzYWlk Lg0KDQpBbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIgcmVxdWlyZW1lbnQsIGZv ciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzK3N1YiBwYWlyIGF0IHRoZSB0 b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS4NCg0KTWFyaXVzDQoNCk9uIFdlZCwgSnVu IDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQorMQ0KDQpQaGlsDQoNCk9u IEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJp Y2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCk1p a2UsDQoNCllvdXIgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGlzIGlzIGEgbm9uLXByb2JsZW0gaXMg ZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3RzIG9mIGVsZW1lbnRzIG9mIE9wZW5JRCBDb25uZWN0 IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4gQXMgYSByZXN1bHQs IEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGggaXQ6DQoNCjEuICAgICAgIFRoZSBjYWxsZXIgb2Yg dGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQgY2FuIGJlIGNlcnRhaW4g dGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFy dHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkg dG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLg0KDQoyLiAgICAgICBBbnkgZnV0dXJlIElEIFRva2Vu IGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLg0K DQozLiAgICAgIE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgIm5vbmNl 4oCdIGNsYWltLg0KDQo0LiAgICAgIFRoaXMgaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tl bnMuIEV2ZXJ5IG90aGVyIEpXVCBwcm9maWxlIHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRp b24gaGFzIHRvIGludmVudCBpdHMgb3duIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLg0KDQpXZSBr bm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5hbWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0 YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBoYXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2Vk IGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3Ug YnJvdWdodCB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRpb24gYWN0dWFsbHkgbWFr ZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24gbGlicmFyaWVzIGZvciBKV1QgcGFyc2luZy4gQSDi gJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFyeSBjb3VsZCBoYW5kbGUgZGlzYW1iaWd1YXRpb24g Zm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVhcyB3aXRoIHRoZSBzdGF0dXMgcXVvIGVhY2ggcHJv ZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDE0LCAy MDE3IGF0IDE6MTYgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5j b208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bT4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpTdWJqZWN0 OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBh bmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpZb3XigJl2ZSBoZWFyZCBvZiDigJxwcmVtYXR1cmUg b3B0aW1pemF0aW9u4oCdLiAgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhp cyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdz IHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhvdXQgZGF0YSBzaG93 aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBkbyBzby4NCg0KTWFuZGF0b3J5IHNvbHV0aW9ucyBh cmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhpcyB0aHJlYWQgdG8gcHJvYmxlbXMgdGhhdCB0aGVyZeKA mXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBhY3R1YWxseSBldmVuIGhhdmUuICBJdOKAmXMgYWxyZWFk eSBiZWVuIGVzdGFibGlzaGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJl IGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDigJMgc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQyOC5odG1sPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZkPUR3TUdh USZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlS ckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3 ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWVLTFRRUG1ZclYzVGhmRGJuOTBTQ3M1NVVST1RQ aW5fbGdjNlJkcjVYb3cmZT0+LiAgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93aW5nIHRoYXQgdGhp cyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBUb2tlbnMgb3Igb3Ro ZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNpZmljcywgc28gdGhh dCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0gYXBwcm9wcmlhdGUgZW5naW5lZXJpbmcg Y2hvaWNlcyBvbiBvdXIgcGFydC4NCg0KVGhlIHByb3Bvc2VkIOKAnHNvbHV0aW9uc+KAnSwgc3Vj aCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0aGUgbm9ybWFsIHdheSwg b3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2aW91c2x5IHNpbXBsZSB0 aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4LiAgWWVzLCB0aGVuIHRoZSByZXN1bHQgaXMgdGhl biBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ugb2YgdGhpcyBp cyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1c2VkLCByYXRoZXIg dGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuICBUaGUgbW9yZSB1bndpZWxkeSB3ZSBtYWtlIGl0 IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxvcGVycyBhcmUgdG8ganVzdCBjcmVh dGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4gIEtlZXBpbmcgaXQgc2ltcGxlIGlzIHRoZSBr ZXkgdG8gYWRvcHRpb24uICBTdGFuZGFyZHMgYXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkgYXJlIGFj dHVhbGx5IHVzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUNClNlbnQ6 IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNTozMyBQTQ0KVG86IE1hcml1cyBTY3VydGVzY3UgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj47IEhlbmsg Qmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmly a2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KQ2M6IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlk LWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog W0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlz dGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hvaW5nIE1hcml1c+KAmXMgcXVlc3Rpb246IGNhbiB5b3Ug ZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT8NCg0KVG8geW91ciBmaXJzdCBx dWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBLZXkg VXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVzIHRo ZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1heSBy ZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNjZXB0IGEgSldUIGJlaW5nIHBy ZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBC YWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNj dXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6 MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl PG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMg TWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBj b25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KT24gVHVlLCBKdW4gMTMsIDIwMTcg YXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+IHdyb3RlOg0KQW5kIGEg Mm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFudGljcyB3b3VsZCAidXNhZ2UiIHByb3ZpZGUgdGhh dCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEgImludGVuZCIsICJhdWRpZW5jZSIsIGFuZCAic2Nv cGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNwZWNpZmllcyB0aGUgdGFyZ2V0IGNsaWVudCwgYnV0 IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tlbiB0byBhdXRob3JpemUgcmVzb3Vy Y2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNlY3VyaXR5IGV2ZW50PykNCg0KInNj b3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoNCkkgZG9uJ3Qga25vdyB3aGF0IGRvIHlvdSBtZWFu IGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0KDQoNCg0KDQpIZW5rDQoNCk9uIDA2LzEzLzIwMTcg MDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOg0KVGhhbmtzIGZvciBw dXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50 IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dlIGNhbuKAmXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkg dHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBj bGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQgZW5mb3JjaW5nIHRoaXMgcmVxdWly ZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFpbeKAnSBhcHByb2FjaCB0byBlbnN1 cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBjYW7igJl0IGJlIG1pc3Rha2VuIGZv ciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3SXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhw ZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZvciBk aWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBz cGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2lu ZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50IGtleXMuDQoNCsK3 RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy4NCg0KKzEgZm9yIGEg4oCc dHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1ldGVyLg0KDQotLQ0KDQpB bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCklkZW50aXR5IFNlcnZpY2VzDQoNCipGcm9tOiAq SWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5j b208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEy LCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29v Z2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCipDYzogKkFkYW0gRGF3ZXMg PGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4+LCAibWF0YWtlLCBu b3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPj4sIElEIEV2ZW50cyBNYWls aW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCAi UGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KQWdyZWVkLiBO b3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxk IGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4gMTIsIDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNj dXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2ds ZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRoZSBwb2ludGVyIERpY2ssIHZlcnkg Z29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICIyLjcuIENy b3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBtaXRpZ2F0aW9uIGlzIGluICIzLjkuIFVz ZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3INCiAgICBEaWZmZXJlbnQg S2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNlIGRpZmZlcmVudCBzZXRzIG9mDQogICAg cmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtp bmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZlcmVudCBpc3N1ZXJzIGZvciBkaWZmZXJl bnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGlsbCB0aGluayB0aGF0IGEgInR5cGUiIGNs YWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kDQogICAgc2FmZXR5Lg0KDQoNCiAg ICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPg0KICAg IDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t Pj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtlIGFuZCBJIGp1c3QgcHVibGlzaGVkIGFu IEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE2OTA8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NlbGYt MkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZzPWE3WHZaNWpUYnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpNY1VJVVEmZT0+DQoNCiAg ICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMgPGFkYXdlc0Bn b29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgPG1haWx0bzphZGF3 ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICAg ICAgICAgIEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMgdG8gYmUgdmVyeSBz aW1pbGFyIHRvDQogICAgICAgICAgICBpZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMg YSBiZXR0ZXIgcGxhbi4NCg0KICAgICAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA2OjU2 IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPg0KICAg ICAgICAgICAgPG1haWx0bzpub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPj4+IHdy b3RlOg0KDQogICAgICAgICAgICAgICAgKzEgZXNwZWNpYWxseSBmb3IgInR5cGUiDQoNCiAgICAg ICAgICAgICAgICAyMDE3LTA2LTA5IDEwOjMyIEdNVCswOTowMCBQaGlsIEh1bnQgKElETSkNCiAg ICAgICAgICAgICAgICA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT4+PjoNCg0KICAgICAgICAgICAgICAgICAgICArMQ0KDQogICAgICAgICAgICAgICAg ICAgIFBoaWwNCg0KDQogICAgICAgICAgICAgICAgICAgICA+IE9uIEp1biA4LCAyMDE3LCBhdCA2 OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAgICAgICAgICAgICAgIDxtc2N1cnRlc2N1 QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgICAg ICAgICAgPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbT4+PiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAg ICAgICAgID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvDQogICAg ICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2Vz cyBUb2tlbnMgaW4NCiAgICAgICAgICAgICAgICAgICAgc3VjaCBhIHdheSB0aGF0IG5haXZlIGlt cGxlbWVudGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAgICAgICAgICAgICBjb25mdXNlIG9uZSBm b3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5DQogICAgICAgICAgICAgICAgICAgIHZ1 bG5lcmFiaWxpdGllcy4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAg ICAgID4gVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlDQog ICAgICAgICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZl cmVudCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAic3ViIiBpc3N1ZXIuIFRoaXMgaXMg dGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQogICAgICAgICAgICAgICAgICAgIHRvIGFu IElkUC4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gV2l0 aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlDQogICAgICAgICAgICAg ICAgICAgIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgID4gLSBib3RoICJzdWIiIGFu ZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudA0KICAgICAgICAgICAgICAgICAgICBs ZXZlbA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGF0IGV2ZW50IGxldmVsIGFuZCBh dCB0b3AgU0VUIGxldmVsIGNhbg0KICAgICAgICAgICAgICAgICAgICBiZSBkaWZmZXJlbnQNCiAg ICAgICAgICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQgInN1YiIgYXQgZXZlbnQgbGV2ZWwgY2Fu IGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICBhY3Jvc3MgZXZlbnRzIGluIHRoZSBz YW1lIFNFVA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJzdWIiIHNob3VsZCBOT1QgYmUgcHJl c2VudCBhdCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAgICAgICAgICBsZXZlbCAodGhpcyBzb2x2 ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUNCiAgICAgICAgICAgICAgICAgICAg InNob3VsZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAg ICAgICAgICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQgcHJvZmls ZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVmaW5l IGFkZGl0aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAgICAgICAgIHJlbGF0ZWQgdG8gc3ViIChs aWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kDQogICAgICAgICAgICAgICAgICAgIHNpbmNl IGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWwNCiAgICAgICAgICAg ICAgICAgICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS4NCiAgICAg ICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5vdGhlciBwcm9wb3Nh bCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUg YSBjb21wb3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmcNCiAgICAgICAgICAg ICAgICAgICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0ICBTRVQgaXNzdWVyLiBBbHNv LA0KICAgICAgICAgICAgICAgICAgICBoYXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcg ZGlmZmVyZW50IHN5bnRheA0KICAgICAgICAgICAgICAgICAgICBpbiBkaWZmZXJlbnQgdG9rZW4g dHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uDQogICAgICAgICAgICAgICAgICAgICA+DQog ICAgICAgICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50 cm9kdWNlIGEgbmV3DQogICAgICAgICAgICAgICAgICAgIGNsYWltIGZvciBKV1RzIHRoYXQgZGVm aW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAgICAgICAgICAgICAgICAgcHJhY3RpY2Fs IGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3QNCiAgICAgICAgICAgICAgICAg ICAgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBidXQgSSB0aGluaw0K ICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNob3Vs ZCBzZXJpb3VzbHkNCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIuDQogICAgICAgICAgICAg ICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRob3VnaHRzPw0KICAgICAgICAgICAg ICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBNYXJpdXMNCg0KICAgICAgICAgICAg ICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAg ICAgICAgICAgICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn PiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQog ICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJm09Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZz PTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmZT0NCg0KICAgICAg ICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAg ICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAg ICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdU bUdNU1dXcyZlPT4NCg0KICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBs aXN0DQogICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGll dGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4+DQogICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3 NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3 b01VN1RtR01TV1dzJmU9Pg0KDQogICAgICAgICAgICAtLQ0KICAgICAgICAgICAgQWRhbSBEYXdl cyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbT4NCiAgICAgICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb208bWFpbHRv OmFkYXdlc0Bnb29nbGUuY29tPj4gfCsxIDY1MC0yMTQtMjQxMDx0ZWw6JTJCMSUyMDY1MC0yMTQt MjQxMD4NCiAgICAgICAgICAgIDx0ZWw6KDY1MCklMjAyMTQtMjQxMDx0ZWw6JTI4NjUwJTI5JTIw MjE0LTI0MTA+Pg0KDQogICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAg ICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJv YWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4N Cg0KICAgICAgICAtLQ0KICAgICAgICBTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSA8aHR0cDov L2hhcmR0d2FyZS5jb20vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJWODAmZT0+PiBtYWls IGxpc3QgdG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0K DQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUu Y29tLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f aGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1pNzVVdzhh ZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFpbCBsaXN0IHRvIGxl YXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QN CklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZ VHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVH enNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlz dA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NY NVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19s TElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21a dUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBs aXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQoNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dA0KDQoNCg== --_000_CY4PR21MB0504CD98555BB5CEF0182DFAF5C40CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTQ0NDE3MTQ0NDg3MjEw NzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGxpLm00NDQxNzE0NDQ4 NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoLCBkaXYubTQ0NDE3 MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLW5hbWU6bV80NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29s aXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTgzOTg1MzQ4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc0OTU1NDg4O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTA3Nzk0ODM4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxNDc2NzE2MTM4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6NjAwNzk4NDU3 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU3NzU3Mjk3MDt9DQpAbGlzdCBsMjpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz DQoJe21zby1saXN0LWlkOjY4Nzk1MDU4NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTYzNjc1 MjMyODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjgwNzY2OTIxODsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTExOTE5NjgwOTA7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNQ0KCXttc28t bGlzdC1pZDo5Mzk0MDcyNDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTM0MzE0MzE2O30N CkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDYNCgl7bXNvLWxpc3QtaWQ6MTU0ODU2NDQyMjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTEwNjY0NzE2NzQ7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNw0KCXttc28tbGlzdC1p ZDoxODk4NzQxMjMzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE0NjE3Njc2NDt9DQpAbGlz dCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWFyaXVzLCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGlu ZyB5b3UgKG9yIHRoZSBSSVNDIHdvcmtpbmcgZ3JvdXAgb3Igb3RoZXIgcHJvZmlsZXMpIGZyb20g ZGVmaW5pbmcgZXZlbnRzIHRoYXQgY2FuIGJlIHNlbnQgZnJvbSBSUHMgdG8gSWRQcyBub3csIHdp dGhvdXQgYW55IGNoYW5nZXMgdG8gdGhlIFNFVCBzcGVjLiZuYnNwOyBTcGVjaWZ5IHRoZSBjbGFp bXMgeW91IHdhbnQNCiB0byB1c2UsIGFuZCB5b3XigJlyZSBnb2xkZW4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5CdXQgaXQgd291bGQgYmUgY291bnRlcnByb2R1Y3RpdmUg dG8gcmVxdWlyZSBhbGwgb3RoZXIgU0VUcyB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgeW91 ciBzcGVjaWZpYyBwcm9maWxlLiZuYnNwOyBUaGVyZSBhcmUgc2ltcGxlciB1c2UgY2FzZXMgdGhh dCBjYW4gdXNlIGNsYWltcyBpbiBzaW1wbGVyIHdheXMuJm5ic3A7IFRyeWluZyB0byBtYWtlIHRo ZSBzaW1wbGUgdXNlDQogY2FzZXMgYmUgY29tcGxleCB3aWxsIGhhdmUgdGhlIHNpZGUgZWZmZWN0 IG9mIGxpbWl0aW5nIHRoZSBhZG9wdGlvbiBvZiB0aGUgc3BlYywgd2hpY2ggd291bGRu4oCZdCBi ZSBnb29kIGZvciBhbnlvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J ZiBzdWNjZXNzZnVsLCBTRVRzIHdpbGwgaGF2ZSBtYW55IGRpZmZlcmVudCBwcm9maWxlcy4mbmJz cDsgVGhhdOKAmXMgYSBzaWduIG9mIHN1Y2Nlc3Mg4oCTIG5vdCBhIHNpZ24gb2Ygd2Vha25lc3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzptc2N1cnRlc2N1QGdv b2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDE5LCAyMDE3IDExOjU4 IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBn bWFpbC5jb20mZ3Q7OyBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7OyBSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs7IEhlbmsg Qmlya2hvbHogJmx0O2hlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUmZ3Q7OyBJRCBFdmVu dHMgTWFpbGluZyBMaXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs7IFBoaWwgSHVudCAmbHQ7 cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFNhdCwgSnVuIDE3LCAyMDE3IGF0IDI6MDYgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPknigJltIHNvcnJ5IHRvIGJlIHNsb3cgcmVwbHlpbmcgdG8gc29tZSBt ZXNzYWdlcyBpbiB0aGlzIHRocmVhZC4mbmJzcDsgSSBoYXZlIGEgbG90IG9mIG90aGVyIHRoaW5n cyBvbiBteSBwbGF0ZSwgYnV0IEkgd2lsbCB0YWtlIHRoZSB0aW1lIG5vdyB0byByZXBseSwgYmVj YXVzZQ0KIEkgd2hvbGVoZWFydGVkbHkgZGlzYWdyZWUgd2l0aCBzb21lIG9mIHRoZSBzdGF0ZW1l bnRzIGJlbG93IGFuZCBiZWxpZXZlIGl0IHdvdWxkIGJlIHNldmVyZWx5IGhhcm1mdWwgdG8gdGhl IHNwZWNpZmljYXRpb24gYW5kIGl0cyBhZG9wdGlvbiB0byBhY3QgdXBvbiB0aGVtLiZuYnNwOyBT cGVjaWZpY2FsbHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjoj MDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNyBsZXZlbDEgbGZvMSI+DQpJIGRpc2FncmVlIHRo YXQgc3BlY2lmaWMgcnVsZXMgc2hvdWxkIGJlIG1hZGUgZm9yIHRoZSDigJxzdWLigJ0gY2xhaW0u Jm5ic3A7IENsYWltcyB1c2FnZSBuZWVkcyB0byBiZSB1cCB0byB0aGUgYXBwbGljYXRpb24uJm5i c3A7IEkga25vdyB0aGF0IG1hbnkgb3RoZXJzIGFncmVlIHdpdGggbWUsIGJlY2F1c2UgdGhlIE9w ZW5JRCBDb25uZWN0IHdvcmtpbmcgZ3JvdXAgZGVzaWduZWQgdGhlIGxvZ291dCB0b2tlbiBpbg0K PGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFja2NoYW5u ZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9rZW4iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9vcGVu aWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJhY2tjaGFubmVsLTFfMC0wNC5odG1sI0xvZ291 dFRva2VuPC9hPiAod2hpY2ggaXMgYWxzbyB1c2VkIGFzIGFuIGV4YW1wbGUgaW4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAx I3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yPC9hPikgdG8gdXNlIHRoZSDi gJxzdWLigJ0gY2xhaW0gaW4gdGhlIG5vcm1hbCB3YXkuJm5ic3A7IFByb2hpYml0aW5nIHRoaXMg dXNhZ2Ugd291bGQgYmUgYSBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5IGJyZWFraW5nIGNoYW5nZSDi gJMgYXMgaXTigJlzIGltcG9zc2libGUgdG8gY29uZnVzZSBhIGxvZ291dCB0b2tlbiB3aXRoIGFu IElEIFRva2VuLCBmb3INCiByZWFzb25zIGFscmVhZHkgY2l0ZXMgaW4gdGhpcyB0aHJlYWQuPG86 cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbHZpbmcgdGhlIGNvbmZ1c2lvbiBpcyBvbmUgcHJvYmxl bS4gVGhlIG90aGVyIHByb2JsZW0gSSBrZWVwIG1lbnRpb25pbmcgaXMgU0VUcyBpc3N1ZWQgYnkg YW4gUlAgdG8gYmUgc2VudCB0byBhbiBJZFAuIEhvdyBhcmUgd2Ugc29sdmluZyB0aGF0IHByb2Js ZW0gTWlrZT8gSW4gdGhpcyBjYXNlIHRoZSB0b3AgbGV2ZWwgaXNzIGlzIGRpZmZlcmVudCBmcm9t IHRoZSBpc3Mgb2YgdGhlIHN1YiwgYSB0b3AgbGV2ZWwNCiBzdWIgaXMgbm90IHBvc3NpYmxlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQg SSBkb24ndCB3YW50IHRvIGRvd25wbGF5IHRoZSBjb25mdXNpb24gcHJvYmxlbSBlaXRoZXIuIEkg dGhpbmsgaXQgaXMgYSByZWFsIGNvbmNlcm4gYW5kIEkgdGhpbmsgYSBzb2xpZCBzb2x1dGlvbiBp cyBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBPcGVuSUQgV29ya2luZyBHcm91cCBkZXNpZ25lZCBsb2dvdXQgdG9rZW5z IHdpdGhvdXQgc2VjZXZlbnQgaW4gbWluZC4gSSBhZ3JlZSB3ZSBzaG91bGQgbm90IHJlY2tsZXNz bHkgYnJlYWsgY29tcGF0aWJpbGl0eSwgYnV0IHRvIG1lIGl0IHNlZW1zIG5lY2Vzc2FyeSBpbiB0 aGlzIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjojMDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNiBsZXZlbDEgbGZvMiI+DQo8bzpwPiZuYnNw OzwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzMiPg0KKEkgYWdyZWUgd2l0aCB0aGUg4oCcaXNz4oCdIHJ1 bGVzIGFscmVhZHkgaW4gcGxhY2UgYXQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yLjEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRv a2VuLTAxI3NlY3Rpb24tMi4xPC9hPi4mbmJzcDsgTm8gZnVydGhlciDigJxpc3PigJ0gcnVsZXMg YXJlIG5lZWRlZC4pPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnVydGhlciBpc3MgcnVpZXMg YXJlIGFic29sdXRlbHkgbmVlZGVkIGZvciB0aGUgUlAgdG8gSWRQIGNhc2UgZGVzY3JpYmVkIGFi b3ZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjoj MDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8bzpwPiZuYnNwOzwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0KSXTigJlzIGZpbmUgZm9yIHRoZSDigJx0eXDigJ0gaGVh ZGVyIHBhcmFtZXRlciB0byBiZSB1c2VkIGZvciBzb21lIHByb2ZpbGVzIHRvIGRpZmZlcmVudGlh dGUgYmV0d2VlbiBraW5kcyBvZiBKV1RzLiZuYnNwOyBJdHMgdXNlIHNob3VsZCBub3QgYmUgbWFu ZGF0ZWQgaW4gdGhlIFNFVCBzcGVjLiZuYnNwOyBJIHdvdWxkIG9wcG9zZSBkdXBsaWNhdGluZyB0 aGUg4oCcdHlw4oCdIGZ1bmN0aW9uYWxpdHkgYnkgZGVmaW5pbmcgYW5vdGhlciBjbGFpbSB3aXRo IGEgZHVwbGljYXRpdmUgbWVhbmluZy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdHlwIGNh biBiZSB1c2UgYW5kIG5vIG90aGVyIGNsYWltIGlzIG5lZWRlZCwgdGhlbiBsZXQncyB0YWxrIGFi b3V0IHRoYXQuIEkgZG8gdGhpbmsgU0VUIHNob3VsZCBtYW5kYXRlIGl0LiBJIGRvbid0IHVuZGVy c3RhbmQgd2h5IG5vdC4gQ2FuIHlvdSBwbGVhc2UgcHJvcG9zZSB3aXRoIGV4YW1wbGVzIGhvdyBj YW4gdHlwIGJlIHVzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNvbG9yOiMwMDIwNjA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm82Ij4NCjxv OnA+Jm5ic3A7PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNyI+DQpJ4oCZbGwgYWxzbyByZXNwb25kIHRv IEFubmFiZWxsZeKAmXMgYXNzZXJ0aW9uIHRoYXQg4oCcPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5ObyBvdGhlciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2UgdGhlICZxdW90O25vbmNl4oCd IGNsYWltLjwvc3Bhbj7igJ0mbmJzcDsgVGhpcyByZWZsZWN0cyBhIG1pc3VuZGVyc3RhbmRpbmcu Jm5ic3A7IEl04oCZcyB0aGUgKjxiPnZhbHVlPC9iPiogb2YgdGhlIG5vbmNlIHRoYXQgc2VsZi1z ZWN1cmVzIHRoZSBKV1Qg4oCTIG5vdCB0aGF0IGFueSDigJxub25jZeKAnQ0KIGNsYWltIGlzIHBy ZXNlbnQuJm5ic3A7IEFueSBhbmQgYWxsIEpXVHMgY2FuIHNpbXVsdGFuZW91c2x5IHVzZSDigJxu b25jZeKAnSB3aXRob3V0IGFueSByaXNrIG9mIGNvbmZsaWN0LCBzaW5jZSB0aGUgbm9uY2UgdmFs dWUgaXMgYSBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUgcmFuZG9tIG51bWJlci48bzpwPjwvbzpw PjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3IgU0VUcyBJIGNhbm5vdCBzZWUgaG93IHRoZSBub25jZSB2YWx1 ZSBpcyB1c2VmdWwuIFRoYXQgdmFsdWUgaXMgbm90IHBhc3NlZCBiYWNrIGFuZCBpdCBjYW5ub3Qg YmUgdmVyaWZpZWQuIE9ubHkgdGhlIHByZXNlbmNlIG9mIHRoZSBjbGFpbSBjb3VsZCBoYXZlIHNv bWUgdXNlLCBoaW50aW5nIGF0IHRoZSB1c2FnZSBvZiB0aGUgSldULCBhIHZlcnkgd2VhayBzb2x1 dGlvbiB0byB0aGUgY29uZnVzaW9uIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZl bDEgbGZvOCI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PldpbGwgc29tZSBvZiB5b3UgYmUgYXQgdGhlIENsb3VkIElkZW50aXR5IFN1bW1pdCBuZXh0IHdl ZWs/Jm5ic3A7IEnigJlkIGJlIGdsYWQgdG8gaGF2ZSBpbi1wZXJzb24gZGlzY3Vzc2lvbnMgYWJv dXQgdGhlc2UgdG9waWNzIHRoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UC5TLiZuYnNwOyBGb29kIGZv ciB0aG91Z2h0OiZuYnNwOyBQcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSAob3IgYW55 IG90aGVyIGNsYWltKSBvciBmb3JjaW5nIGl0IHRvIGJlIGxvY2F0ZWQgaW4gYSBub24tc3RhbmRh cmQgbG9jYXRpb24gbWFrZXMgYWJvdXQgYXMgbXVjaA0KIHNlbnNlIGFzIGFyYml0cmFyaWx5IHNh eWluZyB0aGF0LCBmb3IgYSBwYXJ0aWN1bGFyIHByb2ZpbGUsIHRoZSBMYXRpbiB3b3JkIGZvciBz dWJqZWN0IOKAnHN1YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5hbWUgaW5z dGVhZCBvZiDigJxzdWLigJ0uJm5ic3A7IFllcywgaXQgd2lsbCBjb21wbGV0ZWx5IGRpZmZlcmVu dGlhdGUgdGhpcyBwcm9maWxlIGZyb20gb3RoZXJzIG5vdCBzcGVsbGluZyB0aGUgY2xhaW0gbmFt ZSB0aGlzIHdheSwgYnV0IGl0DQogd291bGQgY2VydGFpbmx5IGJlIGFuIGltcGVkaW1lbnQgdG8g dGhlIHVzZSBvZiBzdGFuZGFyZCBKV1QgbGlicmFyaWVzIGFuZCB0byBpbnRlcm9wZXJhYmlsaXR5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBkZWZpbmUgdGhhdCBzdWIgbXVzdCBi ZSBhdCB0aGUgZXZlbnQgbGV2ZWwgdGhlbiBpdCBpcyBhdCBhIHN0YW5kYXJkIGxvY2F0aW9uLCBJ IGRvbid0IHNlZSB3aGF0IHRoZSBpc3N1ZSBpcy4gVGhlIGltcGVkaW1lbnQgeW91IG1lbnRpb24g aXMgdGhlIGFjdHVhbCBzb2x1dGlvbi4gSSBkb24ndCB0aGluayB0aGF0IGEgSldUIGxpYnJhcnkg dGhhdCB3YXMgd3JpdHRlbiBmb3IgSWQgVG9rZW5zIHNob3VsZA0KIGJlIHVzZWQgdG8gcGFyc2Ug U0VUcy4gVGhlIGxpYnJhcnkgaGFzIHRvIGJlIFNFVCBhd2FyZSwgaW4gd2hpY2ggY2FzZSB0aGUg ZXZlbnQgbGV2ZWwgaXNzJiM0MztzdWIgaXMgbm90IGFuIGlzc3VlIGF0IGFsbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzQ0NDE3MTQ0NDg3MjEwNzcwNTdfX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPkZyb206PC9iPiBZYXJvbiBTaGVmZmVyIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdt YWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bmUgMTcsIDIwMTcg MTo0NSBQTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7 OyBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208 L2E+Jmd0OzsgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBz aXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVu aG9mZXIuZGU8L2E+Jmd0OzsNCiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9y ZzwvYT4mZ3Q7OyBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29u ZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNvIHRvIHN1bW1hcml6ZSB3aGF0IEknbSBzZWVp bmcgb24gdGhpcyB0aHJlYWQ6PG86cD48L286cD48L3A+DQo8cD5FdmVyeWJvZHkgYWdyZWVzIHdp dGggTWFyaXVzJ3Mgc2hvcnQtdGVybSBzb2x1dGlvbiwgc3BlY2lmaWMgcnVsZXMgZm9yICZxdW90 O3N1YiZxdW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7IHRoYXQgY2FuIGJlIGRlZmluZWQgaW4gdGhl IFNFVCBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPHA+QWxtb3N0IGV2ZXJ5Ym9keSBhZ3JlZXMgb24g YSBsb25nLXRlcm0gJnF1b3Q7dXNhZ2UmcXVvdDsgY2xhaW0gKCZxdW90O3R5cGUmcXVvdDsgaXMg dGFrZW4pIHRoYXQgc2hvdWxkIGJlIGRlZmluZWQgZWxzZXdoZXJlLCBlLmcuIGluIHRoZSBKV1Qg QkNQLjxvOnA+PC9vOnA+PC9wPg0KPHA+RGlkIEkgbWlzcyBhbnl0aGluZz88bzpwPjwvbzpwPjwv cD4NCjxwPkJ5IHRoZSB3YXksIGlmIHdlIGRvIGFkZCBhICZxdW90O3VzYWdlJnF1b3Q7IGNsYWlt LCB3ZSBuZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1lbnQgYmVmb3JlIGl0IGlz IHB1Ymxpc2hlZC48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOyZuYnNwOyZuYnNwOyBZYXJvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmljaGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0MzsxIHRvIHRoaXMgYXMgd2Vs bC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBKdW4gMTUsIDIwMTcsIGF0IDE6MDkgUE0sIE1hcml1cyBTY3Vy dGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mIzQzOzEgdG8gd2hhdCBBbm5h YmVsbGUgc2FpZC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFsc28sIE1pa2UgeW91IGFyZSBtaXNzaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudCwg Zm9yIFJQcyB0byBzZW5kIGV2ZW50cyB0byBhbiBJZFAuIFRoZSBpc3MmIzQzO3N1YiBwYWlyIGF0 IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gV2VkLCBKdW4gMTQsIDIwMTcgYXQgNTozMyBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fNDQ0MTcxNDQ0ODcyMTA3NzA1N21fOTA5NDA4OTIzOTY2ODU3MDMxMkFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtXzQ0NDE3MTQ0NDg3MjEwNzcwNTdtXzkwOTQwODkyMzk2Njg1NzAz MTJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QaGlsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gSnVuIDE0LCAyMDE3LCBhdCA1OjI1IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pa2UsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3VyIGV4cGxhbmF0aW9uIGZvciB3aHkgdGhpcyBpcyBh IG5vbi1wcm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNpZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBv ZiBPcGVuSUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNz dWUuIEFzIGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsDQogaXNzdWVzIHdpdGggaXQ6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMx Mm1zb2xpc3RwYXJhZ3JhcGgiPjEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlRoZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBv aW50IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQgY2FuIGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxl c3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2Fs bGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBw cm92ZW5hbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00NDQxNzE0NDQ4NzIxMDc3MDU3 bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj4yLjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5BbnkgZnV0dXJl IElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVt IGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00NDQxNzE0NDQ4NzIxMDc3MDU3bTkw OTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj4zLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5ObyBvdGhlciBwcm9maWxlIG9m IEpXVCBjYW4gZXZlciB1c2UgdGhlICZxdW90O25vbmNl4oCdIGNsYWltLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im00NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29s aXN0cGFyYWdyYXBoIj40LjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj5UaGlzIGlzIG9ubHkgYSBzb2x1dGlvbiBmb3IgSUQgVG9rZW5zLiBF dmVyeSBvdGhlciBKV1QgcHJvZmlsZSB0aGF0IGNhcmVzIGFib3V0IGRpc2FtYmlndWF0aW9uIGhh cyB0byBpbnZlbnQgaXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPldlIGtub3cgZnJvbSBleHBlcmllbmNlIHRoYXQgbmFtaW5nIGNvbGxp c2lvbnMgYW5kIHJlcGxheSBhdHRhY2tzIGFyZSBib3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4gV2hh dOKAmXMgYmVpbmcgcHJvcG9zZWQgaXMgYSBzaW1wbGUsIGRlZmVuc2l2ZSBtZWFzdXJlIGFnYWlu c3QgdGhlc2Ugcmlza3MuIFlvdSBicm91Z2h0DQogdXAgSldUIGxpYnJhcmllczogYSBnZW5lcmFs IHNvbHV0aW9uIGFjdHVhbGx5IG1ha2VzIGl0IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJhcmll cyBmb3IgSldUIHBhcnNpbmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQg aGFuZGxlIGRpc2FtYmlndWF0aW9uIGZvciBhbnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aCB0 aGUgc3RhdHVzIHF1byBlYWNoIHByb2ZpbGUgd291bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbToNCjwv Yj5JZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEp1bmUgMTQsIDIwMTcgYXQgMToxNiBQ TTxicj4NCjxiPlRvOiA8L2I+TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExp c3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDssIEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1h aWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVu ay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFu ZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Zb3XigJl2ZSBoZWFy ZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiZuYnNwOyBJ4oCZZCBjaGFyYWN0ZXJp emUgdGhlIHByb3Bvc2FscyBpbiB0aGlzIHRocmVhZCBhcyDigJxwcmVtYXR1cmUgcGVzc2ltYXRp b27igJ0g4oCTIG1ha2luZyB0aGluZ3MgdGhhdCBjYW4gYW5kIHNob3VsZA0KIGJlIHNpbXBsZSBj b21wbGV4LCB3aXRob3V0IGRhdGEgc2hvd2luZyB0aGVyZeKAmXMgYW55IG5lZWQgdG8gZG8gc28u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWFuZGF0b3J5IHNvbHV0 aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhpcyB0aHJlYWQgdG8gcHJvYmxlbXMgdGhhdCB0 aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBhY3R1YWxseSBldmVuIGhhdmUuJm5ic3A7IEl0 4oCZcyBhbHJlYWR5IGJlZW4gZXN0YWJsaXNoZWQNCiB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZv ciBhIFNFVCB0byBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4g4oCTIHNlZSA8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRldmVudF9jdXJyZW50X21zZzAwNDI4Lmh0 bWwmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtz PWVLTFRRUG1ZclYzVGhmRGJuOTBTQ3M1NVVST1RQaW5fbGdjNlJkcjVYb3cmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2 ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRtbDwvYT4uJm5ic3A7IElmIHBlb3BsZSBoYXZlIGRhdGEg c2hvd2luZyB0aGF0IHRoaXMgaXMgcG9zc2libGUgd2l0aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nl c3MgVG9rZW5zIG9yIG90aGVyIHJlYWwgSldUIGRlcGxveW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBz cGVjaWZpY3MsIHNvIHRoYXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEgdG8gaW5mb3JtDQogYXBwcm9w cmlhdGUgZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGUgcHJvcG9zZWQg4oCcc29sdXRpb25z4oCdLCBzdWNo IGFzIHByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIGluIHRoZSBub3JtYWwgd2F5LCBv ciByZXF1aXJpbmcgYSB0eXBlIGNsYWltLCB3b3VsZCBtYWtlIHByZXZpb3VzbHkgc2ltcGxlIHRo aW5ncyB1bm5lY2Vzc2FyaWx5DQogY29tcGxleC4mbmJzcDsgWWVzLCB0aGVuIHRoZSByZXN1bHQg aXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ugb2Yg dGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1c2VkLCBy YXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuJm5ic3A7IFRoZSBtb3JlIHVud2llbGR5 IHdlIG1ha2UgaXQgdG8gdXNlIFNFVHMsIHRoZSBtb3JlIGxpa2VseSBkZXZlbG9wZXJzIGFyZSB0 bw0KIGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuJm5ic3A7IEtlZXBpbmcg aXQgc2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uJm5ic3A7IFN0YW5kYXJkcyBhcmUgb25s eSB1c2VmdWwgaWYgdGhleSBhcmUgYWN0dWFsbHkgdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBJZC1ldmVudCBbPGEgaHJlZj0ibWFpbHRvOmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNToz MyBQTTxicj4NCjxiPlRvOjwvYj4gTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xl LmNvbTwvYT4mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSUQgRXZlbnRzIE1haWxpbmcg TGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lk LWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGlu Y3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjogY2FuIHlvdSBleHBsYWluIHdoYXQgeW91IG1l YW4gYnkg4oCcaW50ZW5k4oCdPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8geW91ciBm aXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUw OSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xh cmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50 DQogbWF5IHJlZmVyIHRvIHdoZW4gZGV0ZXJtaW5pbmcgd2hldGhlciB0byBhY2NlcHQgYSBKV1Qg YmVpbmcgcHJlc2VudGVkIHRvIGl0IGluIHNvbWUgY29udGV4dC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOg0KPC9iPklkLWV2ZW50ICZsdDs8 YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWFyaXVzIFNj dXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU08YnI+DQo8Yj5UbzogPC9iPkhlbmsg Qmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVy LmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJt YWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZv ciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHog Jmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJn ZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBhIDJuZCBxdWVzdGlvbi48YnI+ DQo8YnI+DQpXaGF0IHNlbWFudGljcyB3b3VsZCAmcXVvdDt1c2FnZSZxdW90OyBwcm92aWRlIHRo YXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICZxdW90O2ludGVuZCZxdW90OywgJnF1b3Q7YXVk aWVuY2UmcXVvdDssIGFuZCAmcXVvdDtzY29wZSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDthdWQmcXVv dDsgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdldCBjbGllbnQsIGJ1dCBub3QgdGhlIGlu dGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0aG9yaXplIHJlc291cmNlIGFjY2VzcyBv ciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1cml0eSBldmVudD8pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtzY29wZSZxdW90 OyBpcyBub3QgdXNlZCBieSBTRVQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IGtub3cgd2hhdCBkbyB5b3UgbWVhbiBieSAm cXVvdDtpbnRlbmQmcXVvdDsgKG9yIGludGVudCk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NCkhlbms8YnI+DQo8YnI+DQpPbiAwNi8x My8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIHB1dHRpbmcgdGhpcyB0b2dldGhl ciE8YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSBhc3N1bXB0aW9ucyBpbmhlcmVudCBpbiAzLjkgYXJl IGZsYXdlZDo8YnI+DQo8YnI+DQrCt1dlIGNhbuKAmXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkgdHlw ZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBjbGFp bXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQgZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMg YSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFpbeKAnSBhcHByb2FjaCB0byBlbnN1cmUg dGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBjYW7igJl0IGJlIG1pc3Rha2VuIGZvciBK V1RzDQogZnJvbSBhIGN1cnJlbnQgc3BlYy48YnI+DQo8YnI+DQrCt0l0IGlzIHVucmVhbGlzdGlj IHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRoZXJlIHRvIHRoZSDigJxkaWZmZXJlbnQga2V5 cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPigJ0gcnVsZS4gV2hldGhlciBtYW5kYXRlZCBi eSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVycyB3aWxsIGlnbm9yZSB0aGlzIGJlY2F1c2Ug bWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhhbiBtYW5hZ2luZyBOIGRpZmZlcmVudCBrZXlz Ljxicj4NCjxicj4NCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy48 YnI+DQo8YnI+DQomIzQzOzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9o ZWFkZXIgcGFyYW1ldGVyLjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW48YnI+DQo8YnI+DQpJZGVudGl0eSBTZXJ2aWNlczxicj4NCjxicj4NCipGcm9t OiAqSWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KKkRh dGU6ICpNb25kYXksIEp1bmUgMTIsIDIwMTcgYXQgMzoxOCBQTTxicj4NCipUbzogKk1hcml1cyBT Y3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCipDYzogKkFkYW0g RGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDssICZxdW90O21hdGFrZSwgbm92JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRh a2UuanA8L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+ Jmd0OywNCiAmcXVvdDtQaGlsIEh1bnQgKElETSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPiZndDs8YnI+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9B Y2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPGJyPg0KPGJyPg0K QWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNjdXNzaW9uIG9uIHdo YXQgc2hvdWxkIGJlIGluIDMuOS48YnI+DQo8YnI+DQpPbiBNb24sIEp1biAxMiwgMjAxNyBhdCAz OjE1IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHRoZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1p bmcgOi0pPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5 ICZxdW90OzIuNy4gQ3Jvc3MtSldUIENvbmZ1c2lvbiZxdW90OyBhbmQgdGhlPGJyPg0KJm5ic3A7 ICZuYnNwOyBtaXRpZ2F0aW9uIGlzIGluICZxdW90OzMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2 ZSBWYWxpZGF0aW9uIFJ1bGVzIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgRGlmZmVyZW50IEtpbmRz IG9mIEpXVHMmcXVvdDssIHNwZWNpZmljYWxseSAmcXVvdDtVc2UgZGlmZmVyZW50IHNldHMgb2Y8 YnI+DQombmJzcDsgJm5ic3A7IHJlcXVpcmVkIGNsYWltcy4uLiZxdW90OywgJnF1b3Q7VXNlIGRp ZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IEpX VHMuJnF1b3Q7IGFuZCAmcXVvdDtVc2UgZGlmZmVyZW50IGlzc3VlcnMgZm9yIGRpZmZlcmVudCBr aW5kcyBvZiBKV1RzLiZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgc3RpbGwgdGhp bmsgdGhhdCBhICZxdW90O3R5cGUmcXVvdDsgY2xhaW0gd291bGQgYnJpbmcgYSBsb3Qgb2YgY2xh cml0eSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IHNhZmV0eS48YnI+DQo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IE1hcml1czxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwg MjAxNyBhdCA5OjU5IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48YnI+ DQombmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyZndDsg d3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFlhcm9uLCBNaWtl IGFuZCBJIGp1c3QgcHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwLTNBX19zZWxmLTJEaXNzdWVkLmluZm9fLTNGcC0zRDE2OTAmYW1wO2Q9 RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm YW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1V c2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWE3WHZaNWpU YnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpNY1VJVVEmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkwPC9hPjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6MDIgUE0gQWRh bSBEYXdlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSB3YXMgaW5pdGlhbGx5 IGEgZmFuIG9mIGtlZXBpbmcgU0VUUyB0byBiZSB2ZXJ5IHNpbWlsYXIgdG88YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpZCB0b2tlbnMgYnV0IEkgbm93IHRo aW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0 YWtlLCBub3YgJmx0OzxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFu ayI+bm92QG1hdGFrZS5qcDwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJn ZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj NDM7MSBlc3BlY2lhbGx5IGZvciAmcXVvdDt0eXBlJnF1b3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyMDE3LTA2LTA5 IDEwOjMyIEdNVCYjNDM7MDk6MDAgUGhpbCBIdW50IChJRE0pPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNs ZS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyZndDs6PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7MTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaGlsPGJy Pg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgT24gSnVuIDgsIDIwMTcsIGF0 IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9 Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1 QGdvb2dsZS5jb208L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1zY3Vy dGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwv YT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcHJvcG9zYWxzIG9uIGhv dyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkaXN0aW5ndWlzaCBTRVRzIGZyb20gSWQgVG9rZW5zIGFu ZCBBY2Nlc3MgVG9rZW5zIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1Y2ggYSB3YXkgdGhhdCBuYWl2 ZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uZnVzZSBvbmUg Zm9yIHRoZSBvdGhlciBhbmQgb3BlbiB1cCBzZWN1cml0eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2dWxu ZXJhYmlsaXRpZXMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBUaGVyZSBpcyBhbHNvIGFub3RoZXIgaW1wb3J0YW50IHJlcXVpcmVtZW50 OiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0VUIGlzc3VlciBpbiBzb21lIGNhc2VzIG11c3QgYmUg ZGlmZmVyZW50IGZyb20gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N1YiZxdW90OyBpc3N1 ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHRvIGFuIElkUC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7IFdpdGggdGhlc2UgcmVxdWlyZW1lbnRzIGluIG1pbmQgSSBwcm9wb3Nl IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb2xsb3dpbmc6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgLSBib3RoICZxdW90O3N1YiZxdW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7IHRvIGJlIGRl ZmluZWQgYXQgdGhlIGV2ZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxldmVsPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsgLSAmcXVvdDtpc3MmcXVvdDsgYXQgZXZlbnQgbGV2ZWwgYW5kIGF0IHRv cCBTRVQgbGV2ZWwgY2FuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlIGRpZmZlcmVudDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDsg YXQgZXZlbnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhY3Jvc3Mg ZXZlbnRzIGluIHRoZSBzYW1lIFNFVDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1 b3Q7c3ViJnF1b3Q7IHNob3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBsZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNl IG5vdGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c2hvdWxkJnF1b3Q7IGFuZCBub3QgJnF1b3Q7 bXVzdCZxdW90Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsgVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQgcHJvZmlsZXMg dGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVmaW5lIGFkZGl0 aW9uYWwgY2xhaW1zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlbGF0ZWQgdG8gc3ViIChsaWtlIGVtYWls IG9yIHBob25lX251bWJlcikgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNpbmNlIGFsbCB0aGVzZSBj bGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUg d2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFub3RoZXIgcHJvcG9zYWwgKHdo aWNoIEkgc3VwcG9ydGVkKSB3YXMgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGEgY29tcG9z aXRlICZxdW90O2F1ZCZxdW90OyBjbGFpbS4gVGhpcyBpcyBub3Qgc29sdmluZzxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB0aGUgcmVxdWlyZW1lbnQgZm9yIGEgZGlzdGluY3QmbmJzcDsgU0VUIGlzc3Vlci4g QWxzbyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaGF2aW5nIHRoZSBzYW1lIGNsYWltIG5hbWUgaGF2aW5n IGRpZmZlcmVudCBzeW50YXg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gZGlmZmVyZW50IHRva2VuIHR5 cGVzIGNvdWxkIGxlYWQgdG8gY29uZnVzaW9uLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgQW5kIHlldCBhbm90aGVyIHByb3Bvc2FsIHdh cyB0byBpbnRyb2R1Y2UgYSBuZXc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2xhaW0gZm9yIEpXVHMgdGhh dCBkZWZpbmVzIGEgJnF1b3Q7dHlwZSZxdW90Oy4gVGhpcyBpcyBub3Q8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3Q8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBidXQg SSB0aGluazxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3Vw IHNob3VsZCBzZXJpb3VzbHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uc2lkZXIuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaG91Z2h0cz88 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 IE1hcml1czxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ow0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4 QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdn ZnhxbWcmYW1wO3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1w O3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT08L2E+ PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4 QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRm Lm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdq NzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUti OXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFkYW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5h Z2VyIHw8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5h ZGF3ZXNAZ29vZ2xlLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDsgfDxhIGhyZWY9InRlbDol MkIxJTIwNjUwLTIxNC0yNDEwIiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxIDY1MC0yMTQtMjQxMDwv YT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEg aHJlZj0idGVsOiUyODY1MCUyOSUyMDIxNC0yNDEwIiB0YXJnZXQ9Il9ibGFuayI+dGVsOig2NTAp JTIwMjE0LTI0MTA8L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQt ZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1 Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFs N2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRF S2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtk PUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209 VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1pNzVVdzhh ZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvYT4mZ3Q7DQogbWFpbCBsaXN0IHRvPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2lu ZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQpTdWJzY3JpYmUgdG8g dGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2ht UWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFH eGhoMVRPclFPVVgyWE1ZQmVyVjgwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9oYXJk dHdhcmUuY29tLzwvYT4mZ3Q7DQogbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkg YW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklk LWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4 QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZl bnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NY NVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktl NENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAw WV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1H TVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NY NVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktl NENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtl PTwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+SWQtZXZlbnQgbWFpbGluZyBsaXN0PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQ8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY4PR21MB0504CD98555BB5CEF0182DFAF5C40CY4PR21MB0504namp_-- From nobody Mon Jun 19 14:43:37 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42BE126D74 for ; Mon, 19 Jun 2017 14:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1jY3SMlzqc5 for ; Mon, 19 Jun 2017 14:43:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17C6129401 for ; Mon, 19 Jun 2017 14:43:29 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5JLhNKR002450 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jun 2017 21:43:24 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5JLhMGK008307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jun 2017 21:43:23 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5JLhLcg007787; Mon, 19 Jun 2017 21:43:21 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Jun 2017 14:43:20 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-20CF37DD-4206-4EB1-ACC8-A3BA4326DF80 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 19 Jun 2017 14:43:18 -0700 Cc: Marius Scurtescu , Yaron Sheffer , Justin Richer , "Richard Backman, Annabelle" , Henk Birkholz , ID Events Mailing List , openid-specs-ab@lists.openid.net Content-Transfer-Encoding: 7bit Message-Id: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39! @mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> To: Mike Jones X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 21:43:35 -0000 --Apple-Mail-20CF37DD-4206-4EB1-ACC8-A3BA4326DF80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike Cc: openid connect list=20 [personal hat] I believe that your position severely limits the value of having a SET spec.= =20 If logout has different parsing rules than the other specs, interop is compr= omised due to different handling for different security components.=20 As I said before, within the context of OpenId, I feel backchannel logout is= too narrowly defined and many other logout and session events will be neede= d that are user triggered depending on scenario.=20 Marius's point is important.=20 For example we want to let the IDP know a subject has logged out of a specif= ic RP. This is different from a logout command which signals single-logout /= SLO at the OP to all RPs. In this case the SET is issued by the RP and not= the OP/IDP.=20 Phil > On Jun 19, 2017, at 2:27 PM, Mike Jones wrot= e: >=20 > Marius, there=E2=80=99s nothing stopping you (or the RISC working group or= other profiles) from defining events that can be sent from RPs to IdPs now,= without any changes to the SET spec. Specify the claims you want to use, a= nd you=E2=80=99re golden. > =20 > But it would be counterproductive to require all other SETs to meet the re= quirements of your specific profile. There are simpler use cases that can u= se claims in simpler ways. Trying to make the simple use cases be complex w= ill have the side effect of limiting the adoption of the spec, which wouldn=E2= =80=99t be good for anyone. > =20 > If successful, SETs will have many different profiles. That=E2=80=99s a s= ign of success =E2=80=93 not a sign of weakness. > =20 > -- Mike > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Monday, June 19, 2017 11:58 AM > To: Mike Jones > Cc: Yaron Sheffer ; Justin Richer = ; Richard Backman, Annabelle ; Henk Birkholz ; ID Events Mailing List ; Phil Hu= nt > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones w= rote: > I=E2=80=99m sorry to be slow replying to some messages in this thread. I h= ave a lot of other things on my plate, but I will take the time now to reply= , because I wholeheartedly disagree with some of the statements below and be= lieve it would be severely harmful to the specification and its adoption to a= ct upon them. Specifically: > =20 > I disagree that specific rules should be made for the =E2=80=9Csub=E2=80=9D= claim. Claims usage needs to be up to the application. I know that many o= thers agree with me, because the OpenID Connect working group designed the l= ogout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.htm= l#LogoutToken (which is also used as an example in https://tools.ietf.org/ht= ml/draft-ietf-secevent-token-01#section-2) to use the =E2=80=9Csub=E2=80=9D c= laim in the normal way. Prohibiting this usage would be a completely unnece= ssary breaking change =E2=80=93 as it=E2=80=99s impossible to confuse a logo= ut token with an ID Token, for reasons already cites in this thread. > Solving the confusion is one problem. The other problem I keep mentioning i= s SETs issued by an RP to be sent to an IdP. How are we solving that problem= Mike? In this case the top level iss is different from the iss of the sub, a= top level sub is not possible. > =20 > And I don't want to downplay the confusion problem either. I think it is a= real concern and I think a solid solution is important. > =20 > The OpenID Working Group designed logout tokens without secevent in mind. I= agree we should not recklessly break compatibility, but to me it seems nece= ssary in this case. > =20 > =20 > =20 > (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at https://= tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1. No further =E2= =80=9Ciss=E2=80=9D rules are needed.) > =20 > Further iss ruies are absolutely needed for the RP to IdP case described a= bove. > =20 > =20 > =20 > =20 > It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be use= d for some profiles to differentiate between kinds of JWTs. Its use should n= ot be mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D functionality by defining another claim with a duplicative meaning= . > If typ can be use and no other claim is needed, then let's talk about that= . I do think SET should mandate it. I don't understand why not. Can you plea= se propose with examples how can typ be used? > =20 > =20 > =20 > =20 > I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CN= o other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D Thi= s reflects a misunderstanding. It=E2=80=99s the *value* of the nonce that s= elf-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is p= resent. Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D wit= hout any risk of conflict, since the nonce value is a cryptographically secu= re random number. > =20 > For SETs I cannot see how the nonce value is useful. That value is not pas= sed back and it cannot be verified. Only the presence of the claim could hav= e some use, hinting at the usage of the JWT, a very weak solution to the con= fusion problem. > =20 > =20 > =20 > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d b= e glad to have in-person discussions about these topics there. > =20 > -- Mike > =20 > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or a= ny other claim) or forcing it to be located in a non-standard location makes= about as much sense as arbitrarily saying that, for a particular profile, t= he Latin word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the cl= aim name instead of =E2=80=9Csub=E2=80=9D. Yes, it will completely differen= tiate this profile from others not spelling the claim name this way, but it w= ould certainly be an impediment to the use of standard JWT libraries and to i= nteroperability. > =20 > If we define that sub must be at the event level then it is at a standard l= ocation, I don't see what the issue is. The impediment you mention is the ac= tual solution. I don't think that a JWT library that was written for Id Toke= ns should be used to parse SETs. The library has to be SET aware, in which c= ase the event level iss+sub is not an issue at all. > =20 > =20 > =20 > =20 > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 > Sent: Saturday, June 17, 2017 1:45 PM > To: Justin Richer ; Marius Scurtescu > Cc: Richard Backman, Annabelle ; Mike Jones ; Henk Birkholz ; ID Ev= ents Mailing List ; Phil Hunt >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > So to summarize what I'm seeing on this thread: >=20 > Everybody agrees with Marius's short-term solution, specific rules for "su= b" and "iss" that can be defined in the SET spec. >=20 > Almost everybody agrees on a long-term "usage" claim ("type" is taken) tha= t should be defined elsewhere, e.g. in the JWT BCP. >=20 > Did I miss anything? >=20 > By the way, if we do add a "usage" claim, we need to also use it in the SE= T document before it is published. >=20 > Thanks, >=20 > Yaron >=20 > =20 > On 15/06/17 22:08, Justin Richer wrote: > +1 to this as well. > =20 > =E2=80=94 Justin > =20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu wrot= e: > =20 > +1 to what Annabelle said. > =20 > Also, Mike you are missing the other requirement, for RPs to send events t= o an IdP. The iss+sub pair at the top level is broken in this case. >=20 > Marius > =20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wr= ote: > +1 > =20 > Phil >=20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >=20 > Mike, > =20 > Your explanation for why this is a non-problem is dependent upon side effe= cts of elements of OpenID Connect that were not designed to solve this issue= . As a result, I see several issues with it: > 1. The caller of the Token Endpoint is the only party that can be ce= rtain that a nonce-less ID Token is really an ID Token. Any party that the c= aller passes the ID Token off to has no way to verify its provenance. >=20 > 2. Any future ID Token distribution method needs to solve this probl= em again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile tha= t cares about disambiguation has to invent its own solution to the problem. >=20 > =20 > We know from experience that naming collisions and replay attacks are both= things that happen. What=E2=80=99s being proposed is a simple, defensive me= asure against these risks. You brought up JWT libraries: a general solution a= ctually makes it easier to use common libraries for JWT parsing. A =E2=80=9C= usage-aware=E2=80=9D JWT library could handle disambiguation for any JWT pro= file, whereas with the status quo each profile would require unique logic. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Mike Jones > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > Cc: "Richard Backman, Annabelle" , ID Events Mailing L= ist , Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2=80= =99d characterize the proposals in this thread as =E2=80=9Cpremature pessima= tion=E2=80=9D =E2=80=93 making things that can and should be simple complex,= without data showing there=E2=80=99s any need to do so. > =20 > Mandatory solutions are being proposed in this thread to problems that the= re=E2=80=99s no evidence that we actually even have. It=E2=80=99s already b= een established that it=E2=80=99s impossible for a SET to be confused for an= ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/curre= nt/msg00428.html. If people have data showing that this is possible with sp= ecific kinds of Access Tokens or other real JWT deployments, please provide s= pecifics, so that we can use that data to inform appropriate engineering cho= ices on our part. > =20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2= =80=9Csub=E2=80=9D in the normal way, or requiring a type claim, would make p= reviously simple things unnecessarily complex. Yes, then the result is then= different than a normal JWT but a consequence of this is that custom parsin= g code would have to be used, rather than a standard JWT parser. The more u= nwieldy we make it to use SETs, the more likely developers are to just creat= e their own data structures. Keeping it simple is the key to adoption. Sta= ndards are only useful if they are actually used. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Bac= kman, Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu ; Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80= =9Cintend=E2=80=9D? > =20 > To your first question, I think a better analogy would be the X.509 Key Us= age extension: a multi-valued property that declares the intended purpose of= the JWT, and that a recipient may refer to when determining whether to acce= pt a JWT being presented to it in some context. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Marius Scurtescu <= mscurtescu@google.com> > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via "intend= ", "audience", and "scope"? > =20 > "aud" (audience) specifies the target client, but not the intended usage (= access token to authorize resource access or SET to communicate a security e= vent?) > =20 > "scope" is not used by SET. > =20 > I don't know what do you mean by "intend" (or intent)? > =20 > =20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutual= ly exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ens= ure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a= current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cd= ifferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is e= asier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header pa= rameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event on behalf of Dick Hardt > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID Ev= ents Mailing List , "Phil Hunt (IDM)" > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and disti= nct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be in 3= .9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: >=20 > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YK= OCd0mxPQFJLhxWI&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j= 746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D= > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > =20 --Apple-Mail-20CF37DD-4206-4EB1-ACC8-A3BA4326DF80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Mike

Cc: openid connect list 
<= br>
[personal hat]
I believe that your position severely limits the value of hav= ing a SET spec. 

If logout has different parsing rules than the other sp= ecs, interop is compromised due to different handling for different security= components. 

As I said before, within the context of OpenId, I feel b= ackchannel logout is too narrowly defined and many other logout and session e= vents will be needed that are user triggered depending on scenario. 

M= arius's point is important. 

For example we want to let the IDP know a= subject has logged out of a specific RP. This is different from a logout co= mmand which signals single-logout / SLO at the OP to all RPs.  In this c= ase the SET is issued by the RP and not the OP/IDP. 

Phil

On Jun 19, 2017, at 2:27 PM, Mike J= ones <Michael.Jones@micros= oft.com> wrote:

Marius, there=E2=80=99s= nothing stopping you (or the RISC working group or other profiles) from def= ining events that can be sent from RPs to IdPs now, without any changes to t= he SET spec.  Specify the claims you want to use, and you=E2=80=99re golden.

 

But it would be counter= productive to require all other SETs to meet the requirements of your specif= ic profile.  There are simpler use cases that can use claims in simpler= ways.  Trying to make the simple use cases be complex will have the side effect of limiting the adoption of the s= pec, which wouldn=E2=80=99t be good for anyone.

 

If successful, SETs wil= l have many different profiles.  That=E2=80=99s a sign of success =E2=80= =93 not a sign of weakness.

 

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

 

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Mic= hael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf= .ietf@gmail.com>; Justin Richer <jricher@mit.edu>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de= >; ID Events Mailing List <id-eve= nt@ietf.org>; Phil Hunt <p= hil.hunt@oracle.com>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

I=E2=80=99m sorry to be slow replying t= o some messages in this thread.  I have a lot of other things on my pla= te, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it w= ould be severely harmful to the specification and its adoption to act upon t= hem.  Specifically:

 

Solving the confusion is one problem. The other probl= em I keep mentioning is SETs issued by an RP to be sent to an IdP. How are w= e solving that problem Mike? In this case the top level iss is different fro= m the iss of the sub, a top level sub is not possible.

 

And I don't want to downplay the confusion problem ei= ther. I think it is a real concern and I think a solid solution is important= .

 

The OpenID Working Group designed logout tokens witho= ut secevent in mind. I agree we should not recklessly break compatibility, b= ut to me it seems necessary in this case.

 

  •  

 

=

 

Further iss ruies are absolutely needed for the RP to= IdP case described above.

 

 

  •  

 

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used f= or some profiles to differentiate between kinds of JWTs.  Its use shoul= d not be mandated in the SET spec.  I would oppose duplicating the =E2=80= =9Ctyp=E2=80=9D functionality by defining another claim with a duplicative m= eaning.

If typ can be use and no other claim is needed, then l= et's talk about that. I do think SET should mandate it. I don't understand w= hy not. Can you please propose with examples how can typ be used?=

 

 

  •  

 

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other profile of JWT can ever use the "nonce=E2=80= =9D claim.=E2=80=9D  This reflects a misunderstanding.  It=E2= =80=99s the *value* of the nonce that self-secures the JWT =E2=80=93 n= ot that any =E2=80=9Cnonce=E2=80=9D claim is present.  Any and all JWTs can simultaneously use =E2=80=9Cno= nce=E2=80=9D without any risk of conflict, since the nonce value is a crypto= graphically secure random number.

 

For SETs I cannot see how the nonce value is useful. T= hat value is not passed back and it cannot be verified. Only the presence of= the claim could have some use, hinting at the usage of the JWT, a very weak= solution to the confusion problem.

 

  •  

 

Will some of you be at the Cloud Ident= ity Summit next week?  I=E2=80=99d be glad to have in-person discussion= s about these topics there.

 

      &n= bsp;            =             &nbs= p;            &n= bsp;          -- Mike

 

P.S.  Food for thought:  Pro= hibiting the use of =E2=80=9Csub=E2=80=9D (or any other claim) or forcing it= to be located in a non-standard location makes about as much sense as arbitrarily saying that, for a particular profile, the Latin word f= or subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name instea= d of =E2=80=9Csub=E2=80=9D.  Yes, it will completely differentiate this= profile from others not spelling the claim name this way, but it would certainly be an impediment to the use of standard JWT libraries and t= o interoperability.

 

If we define that sub must be at the event level then= it is at a standard location, I don't see what the issue is. The impediment= you mention is the actual solution. I don't think that a JWT library that w= as written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case the e= vent level iss+sub is not an issue at all.

 

 

 

 

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscurtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microso= ft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules for "s= ub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) th= at should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use it in the S= ET document before it is published.

Thanks,

    Yaron

 

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

 

 =E2=80=94 Justin

 

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote= :

 

+1 to what Annabelle said.

 

Also, Mike you are missing the other requirement, for RPs to send ev= ents to an IdP. The iss+sub pair at the top level is broken in this case.


Marius

 

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrot= e:

+1

 

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= o:p>

Mike,

 

Your explanation for why this is a non-problem is dependent upon sid= e effects of elements of OpenID Connect that were not designed to solve this= issue. As a result, I see several issues with it:

1.&n= bsp;      The caller of the Token Endpoint is the only party that can be certai= n that a nonce-less ID Token is really an ID Token. Any party that the calle= r passes the ID Token off to has no way to verify its provenance.=

2.&n= bsp;      Any future ID Token distribution method needs to solve this problem a= gain.

3.&n= bsp;     No other profile of JWT can ever use the "nonce=E2=80=9D claim.<= /o:p>

4.&n= bsp;     This is only a solution for ID Tokens. Every other JWT profile that c= ares about disambiguation has to invent its own solution to the problem.

 

We know from experience that naming collisions and replay attacks ar= e both things that happen. What=E2=80=99s being proposed is a simple, defens= ive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common= libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library coul= d handle disambiguation for any JWT profile, whereas with the status quo eac= h profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microso= ft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List= <id-event@ietf.or= g>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

You=E2=80=99ve heard of =E2=80=9Cprema= ture optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in t= his thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making thing= s that can and should be simple complex, without data showing there=E2=80=99s any need to do so.<= /span>

 

Mandatory solutions are being proposed= in this thread to problems that there=E2=80=99s no evidence that we actuall= y even have.  It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80= =93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.&nb= sp; If people have data showing that this is possible with specific kinds of= Access Tokens or other real JWT deployments, please provide specifics, so t= hat we can use that data to inform appropriate engineering choices on our part.

 

The proposed =E2=80=9Csolutions=E2=80=9D= , such as prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, or= requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but= a consequence of this is that custom parsing code would have to be used, ra= ther than a standard JWT parser.  The more unwieldy we make it to use S= ETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key t= o adoption.  Standards are only useful if they are actually used.

 

      &n= bsp;            =             &nbs= p;            &n= bsp;   -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.f= raunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D?

 

To your first question, I think a better analogy would be the X.509 K= ey Usage extension: a multi-valued property that declares the intended purpo= se of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it= in some context.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com= >
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunh= ofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend",= "audience", and "scope"?

 

"aud" (audience) specifies the target client, but not the intended u= sage (access token to authorize resource access or SET to communicate a secu= rity event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutually= exclusive set of valid claims and/or header parameters, and enforcing this r= equires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure= that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdif= ferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by t= he spec or not, implementers will ignore this because managing one key is ea= sier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header para= meter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <= adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9= .

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.c= om>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the     mitigation is in "3.9. Use Mutually Exclusive Validation Rules= for
    Different Kinds of JWTs", specifically "Use different sets of<= br>     required claims...", "Use different keys for different kinds o= f
    JWTs." and "Use different issuers for different kinds of JWTs.= ".

    I still think that a "type" claim would bring a lot of clarity= and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID for J= WT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com         <mailto:adawes@google.com>> wrote:

            I was initially a fan of keeping S= ETS to be very similar to
            id tokens but I now think this is a= better plan.

            On Thu, Jun 8, 2017 at 6:56 PM mat= ake, nov <nov@matake.j= p
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "t= ype"

                2017-06-09 10:32 GMT= +09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailt= o:phil.hunt@oracle= .com>>:

                    +1
=
                    Phil

                     = > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <mscurtescu@google.c= om

                   = ; <mailto:mscu= rtescu@google.com>> wrote:
                     = >
                     = > There were a couple of proposals on how to
                    distin= guish SETs from Id Tokens and Access Tokens in
                    such a= way that naive implementations will not
                    confus= e one for the other and open up security
                    vulner= abilities.
                     = >
                     = > There is also another important requirement: the
                    SET is= suer in some cases must be different from the
                    "sub" i= ssuer. This is the case of an RP sending SETs
                    to an I= dP.
                     = >
                     = > With these requirements in mind I propose the
                    follow= ing:
                     = > - both "sub" and "iss" to be defined at the event
                    level<= br>                      = > - "iss" at event level and at top SET level can
                    be dif= ferent
                     = > - "iss" and "sub" at event level can be different
                    across= events in the same SET
                     = > - "sub" should NOT be present at the top SET
                    level (= this solves the disambiguation), please note
                    "shoul= d" and not "must"
                     = >
                     = > This solution also allows different profiles that
                    define= event types to define additional claims
                    relate= d to sub (like email or phone_number) and
                    since a= ll these claims will be at the event level
                    there w= ill be no collisions or ambiguity.
                     = >
                     = > Another proposal (which I supported) was to
                    define= a composite "aud" claim. This is not solving
                    the re= quirement for a distinct  SET issuer. Also,
                    having= the same claim name having different syntax
                    in dif= ferent token types could lead to confusion.
                     = >
                     = > And yet another proposal was to introduce a new
                    claim f= or JWTs that defines a "type". This is not
                    practi= cal in the short term, and it also is not
                    solvin= g the distinct issuer requirement, but I think
                    this i= s something the JWT group should seriously
                    consid= er.
                     = >
                     = > Thoughts?
                     = >
                     = > Marius

                     = > _______________________________________________
                     = > Id-event mailing list

                    &nbs= p;> Id-event@ietf.org= <mailto:Id-event@= ietf.org>
                     = >
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_= listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk= KY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuut= Bx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKO= Cd0mxPQFJLhxWI&e=3D

                    ______= _________________________________________
                    Id-eve= nt mailing list
                    Id-event@ietf.org <m= ailto:Id-event@ietf.o= rg>
                    https://www.ietf.org/mailman/listinfo/id-event

                ____________________= ___________________________
                Id-event mailing lis= t
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product Manager |= adawes@google.com=
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            __________________________________= _____________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.c= om/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 



_______________________________________________
Id-event mailing list
Id-event@ietf.or=
g
https://www.ietf.=
org/mailman/listinfo/id-event

 

 

= --Apple-Mail-20CF37DD-4206-4EB1-ACC8-A3BA4326DF80-- From nobody Mon Jun 19 14:50:14 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66C129504 for ; Mon, 19 Jun 2017 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SoqIkjSbEaW for ; Mon, 19 Jun 2017 14:50:08 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ECC1294F0 for ; Mon, 19 Jun 2017 14:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1497909007; x=1529445007; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uMTt40uKMmRWdk1FZXQno04yQ5XzFfnriDs6x4IasHs=; b=TKWpplzpfQX2EkB3t3u5lG9yhSTRVXxKcTf4WdfV94lQEM3UFpzZvigg toO29pMMcLDbfVQwdHEWpz8GZ8FbvqgA14WeD1AwovW69F2gYsP+pIYzN hqrTC8Tb5SitSJjz/6t8cavyh8PfDP+4HHSIziAbHT7xOMfhxXqH4eBVs 4=; X-IronPort-AV: E=Sophos;i="5.39,362,1493683200"; d="scan'208,217";a="654333974" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-6012.iad6.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2017 21:50:00 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-6012.iad6.amazon.com (8.14.7/8.14.7) with ESMTP id v5JLnpOL007879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2017 21:49:58 GMT Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Jun 2017 21:49:58 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Jun 2017 21:49:58 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Mon, 19 Jun 2017 21:49:57 +0000 From: "Richard Backman, Annabelle" To: Mike Jones , Marius Scurtescu CC: Yaron Sheffer , Justin Richer , Henk Birkholz , ID Events Mailing List , Phil Hunt Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwAgAEftACAAJUjgP//9x6AgAG/8QD//9AlgAAO8LsAACLOTQAABCSqAABn9XkAAADCnAAAYBKEgAAFODAA//+RAwA= Date: Mon, 19 Jun 2017 21:49:57 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.209] Content-Type: multipart/alternative; boundary="_000_C35BA428D6814782982A92A20CB4B614amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 21:50:12 -0000 --_000_C35BA428D6814782982A92A20CB4B614amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgcHJvZmlsZXMgYXNzaWduIGZ1cnRoZXIgc2VtYW50aWNzIG9yIHJlc3RyaWN0aW9ucyB0byB0 aGUgc3ViIGNsYWltLCB0aGVuIHRoZXJlIHdpbGwgaW5ldml0YWJseSBiZSBjb25mbGljdHMgYmV0 d2VlbiBwcm9maWxlcyAoZS5nLiBwcm9maWxlIEEgc2F5cyBzdWIgaXMgYW4gSVB2NCBhZGRyZXNz IGJ1dCBwcm9maWxlIEIgc2F5cyBpdOKAmXMgYW4gSVB2NiBhZGRyZXNzLCBvciBwcm9maWxlIEEg c2F5cyBpdOKAmXMgZ2xvYmFsIGJ1dCBwcm9maWxlIEIgc2F5cyBpdOKAmXMgc2NvcGVkIHRvIHRo ZSBpc3N1ZXIpLiBJZiB0aGVzZSBwcm9maWxlcyB3YW50IHRoZWlyIGV2ZW50cyB0byBiZSBhYmxl IHRvIGNvZXhpc3QgaW4gdGhlIHNhbWUgdG9rZW4gYXMgb3RoZXIgcHJvZmlsZXPigJkgZXZlbnRz LCB0aGV5IHdpbGwgaGF2ZSB0byBpbmNsdWRlIHNvbWUgd2F5IHRvIHNwZWNpZnkgdGhlIHN1Ympl Y3Qgd2l0aGluIHRoZSBldmVudCBvYmplY3QgYXMgd2VsbC4NCg0KSWYgd2UgdGhpbmsgdGhhdCBh bGwgb3IgdGhlIHZhc3QgbWFqb3JpdHkgb2YgcHJvZmlsZXMgd2lsbCBtZWV0IHRoZSBhYm92ZSBj cml0ZXJpYSwgdGhlbiBpdCBpcyB3b3J0aCBjb2RpZnlpbmcgdGhpcyBtZWNoYW5pc20gYXQgdGhl IFNFVCBsZXZlbCBzbyBwcm9maWxlcyBkb27igJl0IGhhdmUgdG8ga2VlcCByZWludmVudGluZyB0 aGUgd2hlZWwuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2 aWNlcw0KDQoNCkZyb206IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4N CkRhdGU6IE1vbmRheSwgSnVuZSAxOSwgMjAxNyBhdCAyOjI3IFBNDQpUbzogTWFyaXVzIFNjdXJ0 ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5p ZXRmQGdtYWlsLmNvbT4sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4sICJSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBIZW5rIEJpcmtob2x6 IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPiwgSUQgRXZlbnRzIE1haWxpbmcgTGlz dCA8aWQtZXZlbnRAaWV0Zi5vcmc+LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0K U3ViamVjdDogUkU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25m dXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KTWFyaXVzLCB0aGVyZeKAmXMgbm90aGlu ZyBzdG9wcGluZyB5b3UgKG9yIHRoZSBSSVNDIHdvcmtpbmcgZ3JvdXAgb3Igb3RoZXIgcHJvZmls ZXMpIGZyb20gZGVmaW5pbmcgZXZlbnRzIHRoYXQgY2FuIGJlIHNlbnQgZnJvbSBSUHMgdG8gSWRQ cyBub3csIHdpdGhvdXQgYW55IGNoYW5nZXMgdG8gdGhlIFNFVCBzcGVjLiAgU3BlY2lmeSB0aGUg Y2xhaW1zIHlvdSB3YW50IHRvIHVzZSwgYW5kIHlvdeKAmXJlIGdvbGRlbi4NCg0KQnV0IGl0IHdv dWxkIGJlIGNvdW50ZXJwcm9kdWN0aXZlIHRvIHJlcXVpcmUgYWxsIG90aGVyIFNFVHMgdG8gbWVl dCB0aGUgcmVxdWlyZW1lbnRzIG9mIHlvdXIgc3BlY2lmaWMgcHJvZmlsZS4gIFRoZXJlIGFyZSBz aW1wbGVyIHVzZSBjYXNlcyB0aGF0IGNhbiB1c2UgY2xhaW1zIGluIHNpbXBsZXIgd2F5cy4gIFRy eWluZyB0byBtYWtlIHRoZSBzaW1wbGUgdXNlIGNhc2VzIGJlIGNvbXBsZXggd2lsbCBoYXZlIHRo ZSBzaWRlIGVmZmVjdCBvZiBsaW1pdGluZyB0aGUgYWRvcHRpb24gb2YgdGhlIHNwZWMsIHdoaWNo IHdvdWxkbuKAmXQgYmUgZ29vZCBmb3IgYW55b25lLg0KDQpJZiBzdWNjZXNzZnVsLCBTRVRzIHdp bGwgaGF2ZSBtYW55IGRpZmZlcmVudCBwcm9maWxlcy4gIFRoYXTigJlzIGEgc2lnbiBvZiBzdWNj ZXNzIOKAkyBub3QgYSBzaWduIG9mIHdlYWtuZXNzLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMg U2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBK dW5lIDE5LCAyMDE3IDExOjU4IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IEp1 c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl IDxyaWNoYW5uYUBhbWF6b24uY29tPjsgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZT47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3Jn PjsgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyDQoNCk9uIFNhdCwgSnVuIDE3LCAyMDE3IGF0IDI6MDYgUE0sIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj4gd3JvdGU6DQpJ4oCZbSBzb3JyeSB0byBiZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUg bWVzc2FnZXMgaW4gdGhpcyB0aHJlYWQuICBJIGhhdmUgYSBsb3Qgb2Ygb3RoZXIgdGhpbmdzIG9u IG15IHBsYXRlLCBidXQgSSB3aWxsIHRha2UgdGhlIHRpbWUgbm93IHRvIHJlcGx5LCBiZWNhdXNl IEkgd2hvbGVoZWFydGVkbHkgZGlzYWdyZWUgd2l0aCBzb21lIG9mIHRoZSBzdGF0ZW1lbnRzIGJl bG93IGFuZCBiZWxpZXZlIGl0IHdvdWxkIGJlIHNldmVyZWx5IGhhcm1mdWwgdG8gdGhlIHNwZWNp ZmljYXRpb24gYW5kIGl0cyBhZG9wdGlvbiB0byBhY3QgdXBvbiB0aGVtLiAgU3BlY2lmaWNhbGx5 Og0KDQoNCiAgKiAgIEkgZGlzYWdyZWUgdGhhdCBzcGVjaWZpYyBydWxlcyBzaG91bGQgYmUgbWFk ZSBmb3IgdGhlIOKAnHN1YuKAnSBjbGFpbS4gIENsYWltcyB1c2FnZSBuZWVkcyB0byBiZSB1cCB0 byB0aGUgYXBwbGljYXRpb24uICBJIGtub3cgdGhhdCBtYW55IG90aGVycyBhZ3JlZSB3aXRoIG1l LCBiZWNhdXNlIHRoZSBPcGVuSUQgQ29ubmVjdCB3b3JraW5nIGdyb3VwIGRlc2lnbmVkIHRoZSBs b2dvdXQgdG9rZW4gaW4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFj a2NoYW5uZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9rZW4gKHdoaWNoIGlzIGFsc28gdXNlZCBhcyBh biBleGFtcGxlIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2 ZW50LXRva2VuLTAxI3NlY3Rpb24tMikgdG8gdXNlIHRoZSDigJxzdWLigJ0gY2xhaW0gaW4gdGhl IG5vcm1hbCB3YXkuICBQcm9oaWJpdGluZyB0aGlzIHVzYWdlIHdvdWxkIGJlIGEgY29tcGxldGVs eSB1bm5lY2Vzc2FyeSBicmVha2luZyBjaGFuZ2Ug4oCTIGFzIGl04oCZcyBpbXBvc3NpYmxlIHRv IGNvbmZ1c2UgYSBsb2dvdXQgdG9rZW4gd2l0aCBhbiBJRCBUb2tlbiwgZm9yIHJlYXNvbnMgYWxy ZWFkeSBjaXRlcyBpbiB0aGlzIHRocmVhZC4NClNvbHZpbmcgdGhlIGNvbmZ1c2lvbiBpcyBvbmUg cHJvYmxlbS4gVGhlIG90aGVyIHByb2JsZW0gSSBrZWVwIG1lbnRpb25pbmcgaXMgU0VUcyBpc3N1 ZWQgYnkgYW4gUlAgdG8gYmUgc2VudCB0byBhbiBJZFAuIEhvdyBhcmUgd2Ugc29sdmluZyB0aGF0 IHByb2JsZW0gTWlrZT8gSW4gdGhpcyBjYXNlIHRoZSB0b3AgbGV2ZWwgaXNzIGlzIGRpZmZlcmVu dCBmcm9tIHRoZSBpc3Mgb2YgdGhlIHN1YiwgYSB0b3AgbGV2ZWwgc3ViIGlzIG5vdCBwb3NzaWJs ZS4NCg0KQW5kIEkgZG9uJ3Qgd2FudCB0byBkb3ducGxheSB0aGUgY29uZnVzaW9uIHByb2JsZW0g ZWl0aGVyLiBJIHRoaW5rIGl0IGlzIGEgcmVhbCBjb25jZXJuIGFuZCBJIHRoaW5rIGEgc29saWQg c29sdXRpb24gaXMgaW1wb3J0YW50Lg0KDQpUaGUgT3BlbklEIFdvcmtpbmcgR3JvdXAgZGVzaWdu ZWQgbG9nb3V0IHRva2VucyB3aXRob3V0IHNlY2V2ZW50IGluIG1pbmQuIEkgYWdyZWUgd2Ugc2hv dWxkIG5vdCByZWNrbGVzc2x5IGJyZWFrIGNvbXBhdGliaWxpdHksIGJ1dCB0byBtZSBpdCBzZWVt cyBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlLg0KDQoNCiAgKg0KDQoNCiAgKiAgIChJIGFncmVlIHdp dGggdGhlIOKAnGlzc+KAnSBydWxlcyBhbHJlYWR5IGluIHBsYWNlIGF0IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMi4xLiAg Tm8gZnVydGhlciDigJxpc3PigJ0gcnVsZXMgYXJlIG5lZWRlZC4pDQoNCkZ1cnRoZXIgaXNzIHJ1 aWVzIGFyZSBhYnNvbHV0ZWx5IG5lZWRlZCBmb3IgdGhlIFJQIHRvIElkUCBjYXNlIGRlc2NyaWJl ZCBhYm92ZS4NCg0KDQoNCiAgKg0KDQoNCiAgKiAgIEl04oCZcyBmaW5lIGZvciB0aGUg4oCcdHlw 4oCdIGhlYWRlciBwYXJhbWV0ZXIgdG8gYmUgdXNlZCBmb3Igc29tZSBwcm9maWxlcyB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4ga2luZHMgb2YgSldUcy4gIEl0cyB1c2Ugc2hvdWxkIG5vdCBiZSBt YW5kYXRlZCBpbiB0aGUgU0VUIHNwZWMuICBJIHdvdWxkIG9wcG9zZSBkdXBsaWNhdGluZyB0aGUg 4oCcdHlw4oCdIGZ1bmN0aW9uYWxpdHkgYnkgZGVmaW5pbmcgYW5vdGhlciBjbGFpbSB3aXRoIGEg ZHVwbGljYXRpdmUgbWVhbmluZy4NCklmIHR5cCBjYW4gYmUgdXNlIGFuZCBubyBvdGhlciBjbGFp bSBpcyBuZWVkZWQsIHRoZW4gbGV0J3MgdGFsayBhYm91dCB0aGF0LiBJIGRvIHRoaW5rIFNFVCBz aG91bGQgbWFuZGF0ZSBpdC4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBub3QuIENhbiB5b3UgcGxl YXNlIHByb3Bvc2Ugd2l0aCBleGFtcGxlcyBob3cgY2FuIHR5cCBiZSB1c2VkPw0KDQoNCg0KICAq DQoNCg0KICAqICAgSeKAmWxsIGFsc28gcmVzcG9uZCB0byBBbm5hYmVsbGXigJlzIGFzc2VydGlv biB0aGF0IOKAnE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgIm5vbmNl 4oCdIGNsYWltLuKAnSAgVGhpcyByZWZsZWN0cyBhIG1pc3VuZGVyc3RhbmRpbmcuICBJdOKAmXMg dGhlICp2YWx1ZSogb2YgdGhlIG5vbmNlIHRoYXQgc2VsZi1zZWN1cmVzIHRoZSBKV1Qg4oCTIG5v dCB0aGF0IGFueSDigJxub25jZeKAnSBjbGFpbSBpcyBwcmVzZW50LiAgQW55IGFuZCBhbGwgSldU cyBjYW4gc2ltdWx0YW5lb3VzbHkgdXNlIOKAnG5vbmNl4oCdIHdpdGhvdXQgYW55IHJpc2sgb2Yg Y29uZmxpY3QsIHNpbmNlIHRoZSBub25jZSB2YWx1ZSBpcyBhIGNyeXB0b2dyYXBoaWNhbGx5IHNl Y3VyZSByYW5kb20gbnVtYmVyLg0KDQpGb3IgU0VUcyBJIGNhbm5vdCBzZWUgaG93IHRoZSBub25j ZSB2YWx1ZSBpcyB1c2VmdWwuIFRoYXQgdmFsdWUgaXMgbm90IHBhc3NlZCBiYWNrIGFuZCBpdCBj YW5ub3QgYmUgdmVyaWZpZWQuIE9ubHkgdGhlIHByZXNlbmNlIG9mIHRoZSBjbGFpbSBjb3VsZCBo YXZlIHNvbWUgdXNlLCBoaW50aW5nIGF0IHRoZSB1c2FnZSBvZiB0aGUgSldULCBhIHZlcnkgd2Vh ayBzb2x1dGlvbiB0byB0aGUgY29uZnVzaW9uIHByb2JsZW0uDQoNCg0KICAqDQoNCldpbGwgc29t ZSBvZiB5b3UgYmUgYXQgdGhlIENsb3VkIElkZW50aXR5IFN1bW1pdCBuZXh0IHdlZWs/ICBJ4oCZ ZCBiZSBnbGFkIHRvIGhhdmUgaW4tcGVyc29uIGRpc2N1c3Npb25zIGFib3V0IHRoZXNlIHRvcGlj cyB0aGVyZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KUC5TLiAgRm9vZCBmb3IgdGhvdWdodDogIFByb2hpYml0aW5n IHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIChvciBhbnkgb3RoZXIgY2xhaW0pIG9yIGZvcmNpbmcgaXQg dG8gYmUgbG9jYXRlZCBpbiBhIG5vbi1zdGFuZGFyZCBsb2NhdGlvbiBtYWtlcyBhYm91dCBhcyBt dWNoIHNlbnNlIGFzIGFyYml0cmFyaWx5IHNheWluZyB0aGF0LCBmb3IgYSBwYXJ0aWN1bGFyIHBy b2ZpbGUsIHRoZSBMYXRpbiB3b3JkIGZvciBzdWJqZWN0IOKAnHN1YmllY3R1beKAnSBtdXN0IGJl IHVzZWQgYXMgdGhlIGNsYWltIG5hbWUgaW5zdGVhZCBvZiDigJxzdWLigJ0uICBZZXMsIGl0IHdp bGwgY29tcGxldGVseSBkaWZmZXJlbnRpYXRlIHRoaXMgcHJvZmlsZSBmcm9tIG90aGVycyBub3Qg c3BlbGxpbmcgdGhlIGNsYWltIG5hbWUgdGhpcyB3YXksIGJ1dCBpdCB3b3VsZCBjZXJ0YWlubHkg YmUgYW4gaW1wZWRpbWVudCB0byB0aGUgdXNlIG9mIHN0YW5kYXJkIEpXVCBsaWJyYXJpZXMgYW5k IHRvIGludGVyb3BlcmFiaWxpdHkuDQoNCklmIHdlIGRlZmluZSB0aGF0IHN1YiBtdXN0IGJlIGF0 IHRoZSBldmVudCBsZXZlbCB0aGVuIGl0IGlzIGF0IGEgc3RhbmRhcmQgbG9jYXRpb24sIEkgZG9u J3Qgc2VlIHdoYXQgdGhlIGlzc3VlIGlzLiBUaGUgaW1wZWRpbWVudCB5b3UgbWVudGlvbiBpcyB0 aGUgYWN0dWFsIHNvbHV0aW9uLiBJIGRvbid0IHRoaW5rIHRoYXQgYSBKV1QgbGlicmFyeSB0aGF0 IHdhcyB3cml0dGVuIGZvciBJZCBUb2tlbnMgc2hvdWxkIGJlIHVzZWQgdG8gcGFyc2UgU0VUcy4g VGhlIGxpYnJhcnkgaGFzIHRvIGJlIFNFVCBhd2FyZSwgaW4gd2hpY2ggY2FzZSB0aGUgZXZlbnQg bGV2ZWwgaXNzK3N1YiBpcyBub3QgYW4gaXNzdWUgYXQgYWxsLg0KDQoNCg0KDQpGcm9tOiBZYXJv biBTaGVmZmVyIFttYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0 ZkBnbWFpbC5jb20+XQ0KU2VudDogU2F0dXJkYXksIEp1bmUgMTcsIDIwMTcgMTo0NSBQTQ0KVG86 IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj47 IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tPj4NCkNjOiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFA YW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+OyBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0 bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj47IElEIEV2ZW50cyBNYWlsaW5nIExp c3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+OyBQaGlsIEh1 bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoN ClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29u ZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCg0KU28gdG8gc3VtbWFyaXplIHdoYXQg SSdtIHNlZWluZyBvbiB0aGlzIHRocmVhZDoNCg0KRXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1 cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmljIHJ1bGVzIGZvciAic3ViIiBhbmQgImlz cyIgdGhhdCBjYW4gYmUgZGVmaW5lZCBpbiB0aGUgU0VUIHNwZWMuDQoNCkFsbW9zdCBldmVyeWJv ZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICJ1c2FnZSIgY2xhaW0gKCJ0eXBlIiBpcyB0YWtlbikg dGhhdCBzaG91bGQgYmUgZGVmaW5lZCBlbHNld2hlcmUsIGUuZy4gaW4gdGhlIEpXVCBCQ1AuDQoN CkRpZCBJIG1pc3MgYW55dGhpbmc/DQoNCkJ5IHRoZSB3YXksIGlmIHdlIGRvIGFkZCBhICJ1c2Fn ZSIgY2xhaW0sIHdlIG5lZWQgdG8gYWxzbyB1c2UgaXQgaW4gdGhlIFNFVCBkb2N1bWVudCBiZWZv cmUgaXQgaXMgcHVibGlzaGVkLg0KDQpUaGFua3MsDQoNCiAgICBZYXJvbg0KDQpPbiAxNS8wNi8x NyAyMjowOCwgSnVzdGluIFJpY2hlciB3cm90ZToNCisxIHRvIHRoaXMgYXMgd2VsbC4NCg0KIOKA lCBKdXN0aW4NCg0KT24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1 IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdy b3RlOg0KDQorMSB0byB3aGF0IEFubmFiZWxsZSBzYWlkLg0KDQpBbHNvLCBNaWtlIHlvdSBhcmUg bWlzc2luZyB0aGUgb3RoZXIgcmVxdWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8g YW4gSWRQLiBUaGUgaXNzK3N1YiBwYWlyIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRo aXMgY2FzZS4NCg0KTWFyaXVzDQoNCk9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBo aWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPj4gd3JvdGU6DQorMQ0KDQpQaGlsDQoNCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQ TSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCk1pa2UsDQoNCllvdXIgZXhwbGFuYXRpb24g Zm9yIHdoeSB0aGlzIGlzIGEgbm9uLXByb2JsZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZl Y3RzIG9mIGVsZW1lbnRzIG9mIE9wZW5JRCBDb25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQg dG8gc29sdmUgdGhpcyBpc3N1ZS4gQXMgYSByZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdp dGggaXQ6DQoNCjEuICAgICAgIFRoZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRo ZSBvbmx5IHBhcnR5IHRoYXQgY2FuIGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9r ZW4gaXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3Nl cyB0aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNl Lg0KDQoyLiAgICAgICBBbnkgZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVl ZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLg0KDQozLiAgICAgIE5vIG90aGVyIHByb2Zp bGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgIm5vbmNl4oCdIGNsYWltLg0KDQo0LiAgICAgIFRo aXMgaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBwcm9m aWxlIHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMgb3du IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLg0KDQpXZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0 IG5hbWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhh dCBoYXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUg bWVhc3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3UgYnJvdWdodCB1cCBKV1QgbGlicmFyaWVz OiBhIGdlbmVyYWwgc29sdXRpb24gYWN0dWFsbHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21t b24gbGlicmFyaWVzIGZvciBKV1QgcGFyc2luZy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGli cmFyeSBjb3VsZCBoYW5kbGUgZGlzYW1iaWd1YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hl cmVhcyB3aXRoIHRoZSBzdGF0dXMgcXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1 ZSBsb2dpYy4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZp Y2VzDQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE0NClRvOiBNYXJp dXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbT4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1h em9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGluZyBM aXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgSGVuayBC aXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlv biBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0K DQpZb3XigJl2ZSBoZWFyZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiAgSeKAmWQg Y2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJl IHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUg c2ltcGxlIGNvbXBsZXgsIHdpdGhvdXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0 byBkbyBzby4NCg0KTWFuZGF0b3J5IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhp cyB0aHJlYWQgdG8gcHJvYmxlbXMgdGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBh Y3R1YWxseSBldmVuIGhhdmUuICBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkIHRoYXQg aXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tl biDigJMgc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQv Y3VycmVudC9tc2cwMDQyOC5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2 ZW50X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZzPWVLTFRRUG1ZclYzVGhmRGJuOTBTQ3M1NVVST1RQaW5fbGdjNlJkcjVYb3cmZT0+LiAgSWYg cGVvcGxlIGhhdmUgZGF0YSBzaG93aW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNp ZmljIGtpbmRzIG9mIEFjY2VzcyBUb2tlbnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMs IHBsZWFzZSBwcm92aWRlIHNwZWNpZmljcywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0 byBpbmZvcm0gYXBwcm9wcmlhdGUgZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC4NCg0K VGhlIHByb3Bvc2VkIOKAnHNvbHV0aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNl IG9mIOKAnHN1YuKAnSBpbiB0aGUgbm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFp bSwgd291bGQgbWFrZSBwcmV2aW91c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21w bGV4LiAgWWVzLCB0aGVuIHRoZSByZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1h bCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNv ZGUgd291bGQgaGF2ZSB0byBiZSB1c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJz ZXIuICBUaGUgbW9yZSB1bndpZWxkeSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBs aWtlbHkgZGV2ZWxvcGVycyBhcmUgdG8ganVzdCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0 dXJlcy4gIEtlZXBpbmcgaXQgc2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uICBTdGFuZGFy ZHMgYXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog SWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcg NTozMyBQTQ0KVG86IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+ Pg0KQ2M6IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3Ig SWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hv aW5nIE1hcml1c+KAmXMgcXVlc3Rpb246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5 IOKAnGludGVuZOKAnT8NCg0KVG8geW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRl ciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRp LXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRo ZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5n IHdoZXRoZXIgdG8gYWNjZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNv bnRleHQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNl cw0KDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3Ug PG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRh dGU6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6 IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNp dC5mcmF1bmhvZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBp ZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVu dF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNF VCBpc3N1ZXINCg0KT24gVHVlLCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9s eiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBz aXQuZnJhdW5ob2Zlci5kZT4+IHdyb3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNl bWFudGljcyB3b3VsZCAidXNhZ2UiIHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2 aWEgImludGVuZCIsICJhdWRpZW5jZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2Up IHNwZWNpZmllcyB0aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2Ug KGFjY2VzcyB0b2tlbiB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21t dW5pY2F0ZSBhIHNlY3VyaXR5IGV2ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQu DQoNCkkgZG9uJ3Qga25vdyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQp Pw0KDQoNCg0KDQpIZW5rDQoNCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlIHdyb3RlOg0KVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoN CkkgdGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrC t1dlIGNhbuKAmXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEg bXV0dWFsbHkgZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJh bWV0ZXJzLCBhbmQgZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVj b2duaXplZCBjbGFpbeKAnSBhcHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBm dXR1cmUgc3BlYyBjYW7igJl0IGJlIG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNw ZWMuDQoNCsK3SXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhl cmUgdG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KA nSBydWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJz IHdpbGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFu IG1hbmFnaW5nIE4gZGlmZmVyZW50IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg 4oCcaXNz4oCdIGNsYWltcy4NCg0KKzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBj bGFpbS9oZWFkZXIgcGFyYW1ldGVyLg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFu DQoNCklkZW50aXR5IFNlcnZpY2VzDQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tPj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzog Kk1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tPj4NCipDYzogKkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0 bzphZGF3ZXNAZ29vZ2xlLmNvbT4+LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0 bzpub3ZAbWF0YWtlLmpwPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYu b3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAq UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5k IGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwg bG90cyBvZiBkaXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBK dW4gMTIsIDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29n bGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBU aGFua3MgZm9yIHRoZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBU aGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0 aGUNCiAgICBtaXRpZ2F0aW9uIGlzIGluICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFs aWRhdGlvbiBSdWxlcyBmb3INCiAgICBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmlj YWxseSAiVXNlIGRpZmZlcmVudCBzZXRzIG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVz ZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAi VXNlIGRpZmZlcmVudCBpc3N1ZXJzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQog ICAgSSBzdGlsbCB0aGluayB0aGF0IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9m IGNsYXJpdHkgYW5kDQogICAgc2FmZXR5Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwg SnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlh cm9uLCBNaWtlIGFuZCBJIGp1c3QgcHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAg IGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE2OTA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5 MCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdK UEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWE3WHZaNWpUYnRBMnZqZmFISU1i dkVPcFNCQmxCcGRzRGtJVFpNY1VJVVEmZT0+DQoNCiAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAx NyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbT4NCiAgICAgICAgPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRh d2VzQGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICAgICAgICAgIEkgd2FzIGluaXRpYWxseSBh IGZhbiBvZiBrZWVwaW5nIFNFVFMgdG8gYmUgdmVyeSBzaW1pbGFyIHRvDQogICAgICAgICAgICBp ZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi4NCg0KICAgICAg ICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0 YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPg0KICAgICAgICAgICAgPG1haWx0bzpub3ZAbWF0 YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPj4+IHdyb3RlOg0KDQogICAgICAgICAgICAgICAg KzEgZXNwZWNpYWxseSBmb3IgInR5cGUiDQoNCiAgICAgICAgICAgICAgICAyMDE3LTA2LTA5IDEw OjMyIEdNVCswOTowMCBQaGlsIEh1bnQgKElETSkNCiAgICAgICAgICAgICAgICA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+PjoNCg0KICAgICAgICAg ICAgICAgICAgICArMQ0KDQogICAgICAgICAgICAgICAgICAgIFBoaWwNCg0KDQogICAgICAgICAg ICAgICAgICAgICA+IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1 DQogICAgICAgICAgICAgICAgICAgIDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3Vy dGVzY3VAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgICAgICAgICAgPG1haWx0bzptc2N1cnRlc2N1 QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+PiB3cm90ZToNCiAgICAg ICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhlcmUgd2VyZSBhIGNv dXBsZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvDQogICAgICAgICAgICAgICAgICAgIGRpc3Rpbmd1 aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2VzcyBUb2tlbnMgaW4NCiAgICAgICAgICAg ICAgICAgICAgc3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdA0K ICAgICAgICAgICAgICAgICAgICBjb25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVw IHNlY3VyaXR5DQogICAgICAgICAgICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4NCiAgICAgICAg ICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhlcmUgaXMgYWxzbyBhbm90 aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlDQogICAgICAgICAgICAgICAgICAgIFNFVCBp c3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgICAg ICAgICAgICAgICAic3ViIiBpc3N1ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGlu ZyBTRVRzDQogICAgICAgICAgICAgICAgICAgIHRvIGFuIElkUC4NCiAgICAgICAgICAgICAgICAg ICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gV2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4g bWluZCBJIHByb3Bvc2UgdGhlDQogICAgICAgICAgICAgICAgICAgIGZvbGxvd2luZzoNCiAgICAg ICAgICAgICAgICAgICAgID4gLSBib3RoICJzdWIiIGFuZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0 IHRoZSBldmVudA0KICAgICAgICAgICAgICAgICAgICBsZXZlbA0KICAgICAgICAgICAgICAgICAg ICAgPiAtICJpc3MiIGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbg0KICAg ICAgICAgICAgICAgICAgICBiZSBkaWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAgID4gLSAi aXNzIiBhbmQgInN1YiIgYXQgZXZlbnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudA0KICAgICAgICAg ICAgICAgICAgICBhY3Jvc3MgZXZlbnRzIGluIHRoZSBzYW1lIFNFVA0KICAgICAgICAgICAgICAg ICAgICAgPiAtICJzdWIiIHNob3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVA0KICAg ICAgICAgICAgICAgICAgICBsZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwg cGxlYXNlIG5vdGUNCiAgICAgICAgICAgICAgICAgICAgInNob3VsZCIgYW5kIG5vdCAibXVzdCIN CiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhpcyBzb2x1 dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQgcHJvZmlsZXMgdGhhdA0KICAgICAgICAgICAgICAg ICAgICBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xhaW1zDQogICAg ICAgICAgICAgICAgICAgIHJlbGF0ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25lX251bWJl cikgYW5kDQogICAgICAgICAgICAgICAgICAgIHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBi ZSBhdCB0aGUgZXZlbnQgbGV2ZWwNCiAgICAgICAgICAgICAgICAgICAgdGhlcmUgd2lsbCBiZSBu byBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAg ICAgICAgICAgICAgICAgID4gQW5vdGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdh cyB0bw0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgYSBjb21wb3NpdGUgImF1ZCIgY2xhaW0u IFRoaXMgaXMgbm90IHNvbHZpbmcNCiAgICAgICAgICAgICAgICAgICAgdGhlIHJlcXVpcmVtZW50 IGZvciBhIGRpc3RpbmN0ICBTRVQgaXNzdWVyLiBBbHNvLA0KICAgICAgICAgICAgICAgICAgICBo YXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRheA0KICAgICAg ICAgICAgICAgICAgICBpbiBkaWZmZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25m dXNpb24uDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IEFu ZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3DQogICAgICAgICAg ICAgICAgICAgIGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBu b3QNCiAgICAgICAgICAgICAgICAgICAgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQg aXQgYWxzbyBpcyBub3QNCiAgICAgICAgICAgICAgICAgICAgc29sdmluZyB0aGUgZGlzdGluY3Qg aXNzdWVyIHJlcXVpcmVtZW50LCBidXQgSSB0aGluaw0KICAgICAgICAgICAgICAgICAgICB0aGlz IGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNob3VsZCBzZXJpb3VzbHkNCiAgICAgICAgICAg ICAgICAgICAgY29uc2lkZXIuDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAg ICAgICAgICA+IFRob3VnaHRzPw0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAg ICAgICAgICAgPiBNYXJpdXMNCg0KICAgICAgICAgICAgICAgICAgICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICAg PiBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnRA aWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgICA+DQog ICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZk PUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09Sm11dXRCeDREQVBw NzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zw bjg4WUtPQ2QwbXhQUUZKTGh4V0kmZT0NCg0KICAgICAgICAgICAgICAgICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAg ICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0 Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdt WnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAg ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgSWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50 QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xO S2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMm cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQogICAg ICAgICAgICAtLQ0KICAgICAgICAgICAgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIg fGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAg IDxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4gfCsx IDY1MC0yMTQtMjQxMDx0ZWw6JTJCMSUyMDY1MC0yMTQtMjQxMD4NCiAgICAgICAgICAgIDx0ZWw6 KDY1MCklMjAyMTQtMjQxMDx0ZWw6JTI4NjUwJTI5JTIwMjE0LTI0MTA+Pg0KDQogICAgICAgICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAg ICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xq N0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJ VFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAtLQ0KICAgICAgICBT dWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSA8aHR0cDovL2hhcmR0d2FyZS5jb20vPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29t XyZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdK UEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWk3NVV3OGFlaFl2bHBJWk5MN054 cUd4aGgxVE9yUU9VWDJYTVlCZXJWODAmZT0+PiBtYWlsIGxpc3QgdG8NCiAgICAgICAgbGVhcm4g YWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRv IHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3 NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFP VVgyWE1ZQmVyVjgwJmU9Pj4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0g d29ya2luZyBvbiENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FR JmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdq NzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXln N29NVTdUbUdNU1dXcyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01H YVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJp UnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFs N2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1 eWc3b01VN1RtR01TV1dzJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJE ZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklU WDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50 QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCg0K SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0K --_000_C35BA428D6814782982A92A20CB4B614amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <544CF675A41F1A46803C4E5FDAC5761A@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCnAu bTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgs IGxpLm00NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdy YXBoLCBkaXYubTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3Rw YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV80NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODky Mzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxODM5ODUzNDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzQ5NTU0 ODg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1MDc3OTQ4Mzg7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE0NzY3MTYxMzg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlz dC1pZDo2MDA3OTg0NTc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTc3NTcyOTcwO30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6Njg3OTUwNTg3Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxNjM2NzUyMzI4O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6ODA3 NjY5MjE4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE5MTk2ODA5MDt9DQpAbGlzdCBsNDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw1DQoJe21zby1saXN0LWlkOjkzOTQwNzI0NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE1MzQzMTQzMTY7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDoxNTQ4NTY0NDIy Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA2NjQ3MTY3NDt9DQpAbGlzdCBsNjpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2Omxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3 DQoJe21zby1saXN0LWlkOjE4OTg3NDEyMzM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTQ2 MTc2NzY0O30NCkBsaXN0IGw3OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgcHJvZmlsZXMgYXNzaWduIGZ1 cnRoZXIgc2VtYW50aWNzIG9yIHJlc3RyaWN0aW9ucyB0byB0aGUgc3ViIGNsYWltLCB0aGVuIHRo ZXJlIHdpbGwgaW5ldml0YWJseSBiZSBjb25mbGljdHMgYmV0d2VlbiBwcm9maWxlcyAoZS5nLiBw cm9maWxlIEEgc2F5cyBzdWIgaXMgYW4gSVB2NCBhZGRyZXNzIGJ1dCBwcm9maWxlIEIgc2F5cyBp dOKAmXMgYW4gSVB2NiBhZGRyZXNzLCBvciBwcm9maWxlIEEgc2F5cyBpdOKAmXMNCiBnbG9iYWwg YnV0IHByb2ZpbGUgQiBzYXlzIGl04oCZcyBzY29wZWQgdG8gdGhlIGlzc3VlcikuIElmIHRoZXNl IHByb2ZpbGVzIHdhbnQgdGhlaXIgZXZlbnRzIHRvIGJlIGFibGUgdG8gY29leGlzdCBpbiB0aGUg c2FtZSB0b2tlbiBhcyBvdGhlciBwcm9maWxlc+KAmSBldmVudHMsIHRoZXkgd2lsbCBoYXZlIHRv IGluY2x1ZGUgc29tZSB3YXkgdG8gc3BlY2lmeSB0aGUgc3ViamVjdCB3aXRoaW4gdGhlIGV2ZW50 IG9iamVjdCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSB0aGluayB0aGF0 IGFsbCBvciB0aGUgdmFzdCBtYWpvcml0eSBvZiBwcm9maWxlcyB3aWxsIG1lZXQgdGhlIGFib3Zl IGNyaXRlcmlhLCB0aGVuIGl0IGlzIHdvcnRoIGNvZGlmeWluZyB0aGlzIG1lY2hhbmlzbSBhdCB0 aGUgU0VUIGxldmVsIHNvIHByb2ZpbGVzIGRvbuKAmXQgaGF2ZSB0byBrZWVwIHJlaW52ZW50aW5n IHRoZSB3aGVlbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPklkZW50aXR5IFNlcnZpY2VzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+TWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEp1bmUgMTksIDIwMTcgYXQgMjoyNyBQTTxicj4NCjxi PlRvOiA8L2I+TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29tJmd0Ozxi cj4NCjxiPkNjOiA8L2I+WWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21haWwuY29tJmd0 OywgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0OywgJnF1b3Q7UmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUmcXVvdDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7LCBIZW5r IEJpcmtob2x6ICZsdDtoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlJmd0OywgSUQgRXZl bnRzIE1haWxpbmcgTGlzdCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7LCBQaGlsIEh1bnQgJmx0 O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogW0lkLWV2 ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3Qg U0VUIGlzc3Vlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWFyaXVzLCB0aGVyZeKAmXMgbm90aGlu ZyBzdG9wcGluZyB5b3UgKG9yIHRoZSBSSVNDIHdvcmtpbmcgZ3JvdXAgb3Igb3RoZXIgcHJvZmls ZXMpIGZyb20gZGVmaW5pbmcgZXZlbnRzIHRoYXQgY2FuIGJlIHNlbnQgZnJvbSBSUHMgdG8gSWRQ cyBub3csIHdpdGhvdXQgYW55IGNoYW5nZXMgdG8gdGhlIFNFVCBzcGVjLiZuYnNwOyBTcGVjaWZ5 IHRoZSBjbGFpbXMgeW91IHdhbnQNCiB0byB1c2UsIGFuZCB5b3XigJlyZSBnb2xkZW4uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5CdXQgaXQgd291bGQgYmUgY291bnRlcnBy b2R1Y3RpdmUgdG8gcmVxdWlyZSBhbGwgb3RoZXIgU0VUcyB0byBtZWV0IHRoZSByZXF1aXJlbWVu dHMgb2YgeW91ciBzcGVjaWZpYyBwcm9maWxlLiZuYnNwOyBUaGVyZSBhcmUgc2ltcGxlciB1c2Ug Y2FzZXMgdGhhdCBjYW4gdXNlIGNsYWltcyBpbiBzaW1wbGVyIHdheXMuJm5ic3A7IFRyeWluZyB0 byBtYWtlIHRoZSBzaW1wbGUgdXNlDQogY2FzZXMgYmUgY29tcGxleCB3aWxsIGhhdmUgdGhlIHNp ZGUgZWZmZWN0IG9mIGxpbWl0aW5nIHRoZSBhZG9wdGlvbiBvZiB0aGUgc3BlYywgd2hpY2ggd291 bGRu4oCZdCBiZSBnb29kIGZvciBhbnlvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj5JZiBzdWNjZXNzZnVsLCBTRVRzIHdpbGwgaGF2ZSBtYW55IGRpZmZlcmVudCBwcm9m aWxlcy4mbmJzcDsgVGhhdOKAmXMgYSBzaWduIG9mIHN1Y2Nlc3Mg4oCTIG5vdCBhIHNpZ24gb2Yg d2Vha25lc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvYT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFyaXVzIFNjdXJ0ZXNjdSBbbWFpbHRv Om1zY3VydGVzY3VAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUg MTksIDIwMTcgMTE6NTggQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0 O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDs7IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0 LmVkdSZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYUBhbWF6b24u Y29tJmd0OzsgSGVuayBCaXJraG9seiAmbHQ7aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZSZndDs7IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozsg UGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24g YW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gU2F0LCBKdW4gMTcsIDIwMTcgYXQgMjowNiBQTSwgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPknigJltIHNvcnJ5IHRvIGJlIHNsb3cgcmVwbHlpbmcgdG8gc29tZSBtZXNzYWdl cyBpbiB0aGlzIHRocmVhZC4mbmJzcDsgSSBoYXZlIGEgbG90IG9mIG90aGVyIHRoaW5ncyBvbiBt eSBwbGF0ZSwgYnV0IEkgd2lsbCB0YWtlIHRoZSB0aW1lIG5vdyB0byByZXBseSwgYmVjYXVzZQ0K IEkgd2hvbGVoZWFydGVkbHkgZGlzYWdyZWUgd2l0aCBzb21lIG9mIHRoZSBzdGF0ZW1lbnRzIGJl bG93IGFuZCBiZWxpZXZlIGl0IHdvdWxkIGJlIHNldmVyZWx5IGhhcm1mdWwgdG8gdGhlIHNwZWNp ZmljYXRpb24gYW5kIGl0cyBhZG9wdGlvbiB0byBhY3QgdXBvbiB0aGVtLiZuYnNwOyBTcGVjaWZp Y2FsbHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVs IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYw O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0Omw3IGxldmVsMSBsZm8xIj4NCkkgZGlzYWdyZWUgdGhhdCBzcGVjaWZpYyBydWxlcyBzaG91 bGQgYmUgbWFkZSBmb3IgdGhlIOKAnHN1YuKAnSBjbGFpbS4mbmJzcDsgQ2xhaW1zIHVzYWdlIG5l ZWRzIHRvIGJlIHVwIHRvIHRoZSBhcHBsaWNhdGlvbi4mbmJzcDsgSSBrbm93IHRoYXQgbWFueSBv dGhlcnMgYWdyZWUgd2l0aCBtZSwgYmVjYXVzZSB0aGUgT3BlbklEIENvbm5lY3Qgd29ya2luZyBn cm91cCBkZXNpZ25lZCB0aGUgbG9nb3V0IHRva2VuIGluDQo8YSBocmVmPSJodHRwOi8vb3Blbmlk Lm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1iYWNrY2hhbm5lbC0xXzAtMDQuaHRtbCNMb2dvdXRU b2tlbiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNv bm5lY3QtYmFja2NoYW5uZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9rZW48L2E+ICh3aGljaCBpcyBh bHNvIHVzZWQgYXMgYW4gZXhhbXBsZSBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10 b2tlbi0wMSNzZWN0aW9uLTI8L2E+KSB0byB1c2UgdGhlIOKAnHN1YuKAnSBjbGFpbSBpbiB0aGUg bm9ybWFsIHdheS4mbmJzcDsgUHJvaGliaXRpbmcgdGhpcyB1c2FnZSB3b3VsZCBiZSBhIGNvbXBs ZXRlbHkgdW5uZWNlc3NhcnkgYnJlYWtpbmcgY2hhbmdlIOKAkyBhcyBpdOKAmXMgaW1wb3NzaWJs ZSB0byBjb25mdXNlIGEgbG9nb3V0IHRva2VuIHdpdGggYW4gSUQgVG9rZW4sIGZvcg0KIHJlYXNv bnMgYWxyZWFkeSBjaXRlcyBpbiB0aGlzIHRocmVhZC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U29sdmluZyB0aGUgY29uZnVzaW9uIGlzIG9uZSBwcm9ibGVtLiBUaGUgb3RoZXIgcHJvYmxlbSBJ IGtlZXAgbWVudGlvbmluZyBpcyBTRVRzIGlzc3VlZCBieSBhbiBSUCB0byBiZSBzZW50IHRvIGFu IElkUC4gSG93IGFyZSB3ZSBzb2x2aW5nIHRoYXQgcHJvYmxlbSBNaWtlPyBJbiB0aGlzIGNhc2Ug dGhlIHRvcCBsZXZlbCBpc3MgaXMgZGlmZmVyZW50IGZyb20gdGhlIGlzcyBvZiB0aGUgc3ViLCBh IHRvcCBsZXZlbA0KIHN1YiBpcyBub3QgcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBJIGRvbid0IHdhbnQgdG8gZG93bnBs YXkgdGhlIGNvbmZ1c2lvbiBwcm9ibGVtIGVpdGhlci4gSSB0aGluayBpdCBpcyBhIHJlYWwgY29u Y2VybiBhbmQgSSB0aGluayBhIHNvbGlkIHNvbHV0aW9uIGlzIGltcG9ydGFudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9wZW5JRCBX b3JraW5nIEdyb3VwIGRlc2lnbmVkIGxvZ291dCB0b2tlbnMgd2l0aG91dCBzZWNldmVudCBpbiBt aW5kLiBJIGFncmVlIHdlIHNob3VsZCBub3QgcmVja2xlc3NseSBicmVhayBjb21wYXRpYmlsaXR5 LCBidXQgdG8gbWUgaXQgc2VlbXMgbmVjZXNzYXJ5IGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw2IGxldmVsMSBsZm8yIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVs MSBsZm8zIj4NCihJIGFncmVlIHdpdGggdGhlIOKAnGlzc+KAnSBydWxlcyBhbHJlYWR5IGluIHBs YWNlIGF0IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNl Y2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMi4xIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0wMSNzZWN0aW9uLTIu MTwvYT4uJm5ic3A7IE5vIGZ1cnRoZXIg4oCcaXNz4oCdIHJ1bGVzIGFyZSBuZWVkZWQuKTxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZ1cnRoZXIgaXNzIHJ1aWVzIGFyZSBhYnNvbHV0ZWx5IG5l ZWRlZCBmb3IgdGhlIFJQIHRvIElkUCBjYXNlIGRlc2NyaWJlZCBhYm92ZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KJm5ic3A7PG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzUiPg0KSXTigJlzIGZpbmUgZm9yIHRoZSDigJx0eXDigJ0gaGVhZGVyIHBhcmFtZXRl ciB0byBiZSB1c2VkIGZvciBzb21lIHByb2ZpbGVzIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBr aW5kcyBvZiBKV1RzLiZuYnNwOyBJdHMgdXNlIHNob3VsZCBub3QgYmUgbWFuZGF0ZWQgaW4gdGhl IFNFVCBzcGVjLiZuYnNwOyBJIHdvdWxkIG9wcG9zZSBkdXBsaWNhdGluZyB0aGUg4oCcdHlw4oCd IGZ1bmN0aW9uYWxpdHkgYnkgZGVmaW5pbmcgYW5vdGhlciBjbGFpbSB3aXRoIGEgZHVwbGljYXRp dmUgbWVhbmluZy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdHlwIGNhbiBiZSB1c2UgYW5k IG5vIG90aGVyIGNsYWltIGlzIG5lZWRlZCwgdGhlbiBsZXQncyB0YWxrIGFib3V0IHRoYXQuIEkg ZG8gdGhpbmsgU0VUIHNob3VsZCBtYW5kYXRlIGl0LiBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IG5v dC4gQ2FuIHlvdSBwbGVhc2UgcHJvcG9zZSB3aXRoIGV4YW1wbGVzIGhvdyBjYW4gdHlwIGJlIHVz ZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBs Zm82Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjoj MDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm83Ij4NCknigJlsbCBhbHNvIHJlc3BvbmQgdG8gQW5uYWJl bGxl4oCZcyBhc3NlcnRpb24gdGhhdCDigJw8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5vIG90 aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgJnF1b3Q7bm9uY2XigJ0gY2xhaW0u PC9zcGFuPuKAnSZuYnNwOyBUaGlzIHJlZmxlY3RzIGEgbWlzdW5kZXJzdGFuZGluZy4mbmJzcDsg SXTigJlzIHRoZSAqPGI+dmFsdWU8L2I+KiBvZiB0aGUgbm9uY2UgdGhhdCBzZWxmLXNlY3VyZXMg dGhlIEpXVCDigJMgbm90IHRoYXQgYW55IOKAnG5vbmNl4oCdDQogY2xhaW0gaXMgcHJlc2VudC4m bmJzcDsgQW55IGFuZCBhbGwgSldUcyBjYW4gc2ltdWx0YW5lb3VzbHkgdXNlIOKAnG5vbmNl4oCd IHdpdGhvdXQgYW55IHJpc2sgb2YgY29uZmxpY3QsIHNpbmNlIHRoZSBub25jZSB2YWx1ZSBpcyBh IGNyeXB0b2dyYXBoaWNhbGx5IHNlY3VyZSByYW5kb20gbnVtYmVyLjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZvciBTRVRzIEkgY2Fubm90IHNlZSBob3cgdGhlIG5vbmNlIHZhbHVlIGlzIHVz ZWZ1bC4gVGhhdCB2YWx1ZSBpcyBub3QgcGFzc2VkIGJhY2sgYW5kIGl0IGNhbm5vdCBiZSB2ZXJp ZmllZC4gT25seSB0aGUgcHJlc2VuY2Ugb2YgdGhlIGNsYWltIGNvdWxkIGhhdmUgc29tZSB1c2Us IGhpbnRpbmcgYXQgdGhlIHVzYWdlIG9mIHRoZSBKV1QsIGEgdmVyeSB3ZWFrIHNvbHV0aW9uIHRv IHRoZSBjb25mdXNpb24gcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAy MDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0Omw1IGxldmVsMSBsZm84Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+V2lsbCBzb21lIG9mIHlvdSBiZSBhdCB0aGUgQ2xvdWQgSWRlbnRpdHkg U3VtbWl0IG5leHQgd2Vlaz8mbmJzcDsgSeKAmWQgYmUgZ2xhZCB0byBoYXZlIGluLXBlcnNvbiBk aXNjdXNzaW9ucyBhYm91dCB0aGVzZSB0b3BpY3MgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QLlMu Jm5ic3A7IEZvb2QgZm9yIHRob3VnaHQ6Jm5ic3A7IFByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCc c3Vi4oCdIChvciBhbnkgb3RoZXIgY2xhaW0pIG9yIGZvcmNpbmcgaXQgdG8gYmUgbG9jYXRlZCBp biBhIG5vbi1zdGFuZGFyZCBsb2NhdGlvbiBtYWtlcyBhYm91dCBhcyBtdWNoDQogc2Vuc2UgYXMg YXJiaXRyYXJpbHkgc2F5aW5nIHRoYXQsIGZvciBhIHBhcnRpY3VsYXIgcHJvZmlsZSwgdGhlIExh dGluIHdvcmQgZm9yIHN1YmplY3Qg4oCcc3ViaWVjdHVt4oCdIG11c3QgYmUgdXNlZCBhcyB0aGUg Y2xhaW0gbmFtZSBpbnN0ZWFkIG9mIOKAnHN1YuKAnS4mbmJzcDsgWWVzLCBpdCB3aWxsIGNvbXBs ZXRlbHkgZGlmZmVyZW50aWF0ZSB0aGlzIHByb2ZpbGUgZnJvbSBvdGhlcnMgbm90IHNwZWxsaW5n IHRoZSBjbGFpbSBuYW1lIHRoaXMgd2F5LCBidXQgaXQNCiB3b3VsZCBjZXJ0YWlubHkgYmUgYW4g aW1wZWRpbWVudCB0byB0aGUgdXNlIG9mIHN0YW5kYXJkIEpXVCBsaWJyYXJpZXMgYW5kIHRvIGlu dGVyb3BlcmFiaWxpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGRlZmluZSB0 aGF0IHN1YiBtdXN0IGJlIGF0IHRoZSBldmVudCBsZXZlbCB0aGVuIGl0IGlzIGF0IGEgc3RhbmRh cmQgbG9jYXRpb24sIEkgZG9uJ3Qgc2VlIHdoYXQgdGhlIGlzc3VlIGlzLiBUaGUgaW1wZWRpbWVu dCB5b3UgbWVudGlvbiBpcyB0aGUgYWN0dWFsIHNvbHV0aW9uLiBJIGRvbid0IHRoaW5rIHRoYXQg YSBKV1QgbGlicmFyeSB0aGF0IHdhcyB3cml0dGVuIGZvciBJZCBUb2tlbnMgc2hvdWxkDQogYmUg dXNlZCB0byBwYXJzZSBTRVRzLiBUaGUgbGlicmFyeSBoYXMgdG8gYmUgU0VUIGF3YXJlLCBpbiB3 aGljaCBjYXNlIHRoZSBldmVudCBsZXZlbCBpc3MmIzQzO3N1YiBpcyBub3QgYW4gaXNzdWUgYXQg YWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YSBuYW1lPSJtXzQ0NDE3MTQ0NDg3MjEwNzcwNTdfX01haWxFbmRDb21wb3NlIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPkZyb206PC9iPiBZYXJvbiBTaGVmZmVyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnlh cm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bmUgMTcsIDIwMTcgMTo0NSBQ TTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNo ZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7OyBNYXJp dXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0 OzsgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 OyBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJh dW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIu ZGU8L2E+Jmd0OzsNCiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86 aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4m Z3Q7OyBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9u IGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNvIHRvIHN1bW1hcml6ZSB3aGF0IEknbSBzZWVpbmcgb24g dGhpcyB0aHJlYWQ6PG86cD48L286cD48L3A+DQo8cD5FdmVyeWJvZHkgYWdyZWVzIHdpdGggTWFy aXVzJ3Mgc2hvcnQtdGVybSBzb2x1dGlvbiwgc3BlY2lmaWMgcnVsZXMgZm9yICZxdW90O3N1YiZx dW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7IHRoYXQgY2FuIGJlIGRlZmluZWQgaW4gdGhlIFNFVCBz cGVjLjxvOnA+PC9vOnA+PC9wPg0KPHA+QWxtb3N0IGV2ZXJ5Ym9keSBhZ3JlZXMgb24gYSBsb25n LXRlcm0gJnF1b3Q7dXNhZ2UmcXVvdDsgY2xhaW0gKCZxdW90O3R5cGUmcXVvdDsgaXMgdGFrZW4p IHRoYXQgc2hvdWxkIGJlIGRlZmluZWQgZWxzZXdoZXJlLCBlLmcuIGluIHRoZSBKV1QgQkNQLjxv OnA+PC9vOnA+PC9wPg0KPHA+RGlkIEkgbWlzcyBhbnl0aGluZz88bzpwPjwvbzpwPjwvcD4NCjxw PkJ5IHRoZSB3YXksIGlmIHdlIGRvIGFkZCBhICZxdW90O3VzYWdlJnF1b3Q7IGNsYWltLCB3ZSBu ZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1lbnQgYmVmb3JlIGl0IGlzIHB1Ymxp c2hlZC48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OyZuYnNwOyZuYnNwOyBZYXJvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmljaGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0MzsxIHRvIHRoaXMgYXMgd2VsbC4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO+KA lCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBKdW4gMTUsIDIwMTcsIGF0IDE6MDkgUE0sIE1hcml1cyBTY3VydGVzY3Ug Jmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mIzQzOzEgdG8gd2hhdCBBbm5hYmVsbGUg c2FpZC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFsc28sIE1pa2UgeW91IGFyZSBtaXNzaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudCwgZm9yIFJQ cyB0byBzZW5kIGV2ZW50cyB0byBhbiBJZFAuIFRoZSBpc3MmIzQzO3N1YiBwYWlyIGF0IHRoZSB0 b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NYXJp dXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g V2VkLCBKdW4gMTQsIDIwMTcgYXQgNTozMyBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f NDQ0MTcxNDQ0ODcyMTA3NzA1N21fOTA5NDA4OTIzOTY2ODU3MDMxMkFwcGxlTWFpbFNpZ25hdHVy ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJtXzQ0NDE3MTQ0NDg3MjEwNzcwNTdtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBs ZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QaGlsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K T24gSnVuIDE0LCAyMDE3LCBhdCA1OjI1IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5y aWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pa2UsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Zb3VyIGV4cGxhbmF0aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1w cm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNpZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVu SUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFz IGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsDQogaXNzdWVzIHdpdGggaXQ6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xp c3RwYXJhZ3JhcGgiPjEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPlRoZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBv bmx5IHBhcnR5IHRoYXQgY2FuIGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4g aXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0 aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2 Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj4yLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5BbnkgZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1 dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im00NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJt c29saXN0cGFyYWdyYXBoIj4zLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj5ObyBvdGhlciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2UgdGhlICZx dW90O25vbmNl4oCdIGNsYWltLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im00NDQxNzE0NDQ4 NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj40LjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5UaGlzIGlzIG9ubHkg YSBzb2x1dGlvbiBmb3IgSUQgVG9rZW5zLiBFdmVyeSBvdGhlciBKV1QgcHJvZmlsZSB0aGF0IGNh cmVzIGFib3V0IGRpc2FtYmlndWF0aW9uIGhhcyB0byBpbnZlbnQgaXRzIG93biBzb2x1dGlvbiB0 byB0aGUgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGtub3cgZnJvbSBl eHBlcmllbmNlIHRoYXQgbmFtaW5nIGNvbGxpc2lvbnMgYW5kIHJlcGxheSBhdHRhY2tzIGFyZSBi b3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4gV2hhdOKAmXMgYmVpbmcgcHJvcG9zZWQgaXMgYSBzaW1w bGUsIGRlZmVuc2l2ZSBtZWFzdXJlIGFnYWluc3QgdGhlc2Ugcmlza3MuIFlvdSBicm91Z2h0DQog dXAgSldUIGxpYnJhcmllczogYSBnZW5lcmFsIHNvbHV0aW9uIGFjdHVhbGx5IG1ha2VzIGl0IGVh c2llciB0byB1c2UgY29tbW9uIGxpYnJhcmllcyBmb3IgSldUIHBhcnNpbmcuIEEg4oCcdXNhZ2Ut YXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQgaGFuZGxlIGRpc2FtYmlndWF0aW9uIGZvciBhbnkg SldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aCB0aGUgc3RhdHVzIHF1byBlYWNoIHByb2ZpbGUgd291 bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+RnJvbToNCjwvYj5JZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudC1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIEp1bmUgMTQsIDIwMTcgYXQgMToxNiBQTTxicj4NCjxiPlRvOiA8L2I+TWFyaXVzIFNjdXJ0 ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9h PiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDssIEhl bmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJ ZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5Zb3XigJl2ZSBoZWFyZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u 4oCdLiZuYnNwOyBJ4oCZZCBjaGFyYWN0ZXJpemUgdGhlIHByb3Bvc2FscyBpbiB0aGlzIHRocmVh ZCBhcyDigJxwcmVtYXR1cmUgcGVzc2ltYXRpb27igJ0g4oCTIG1ha2luZyB0aGluZ3MgdGhhdCBj YW4gYW5kIHNob3VsZA0KIGJlIHNpbXBsZSBjb21wbGV4LCB3aXRob3V0IGRhdGEgc2hvd2luZyB0 aGVyZeKAmXMgYW55IG5lZWQgdG8gZG8gc28uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+TWFuZGF0b3J5IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhp cyB0aHJlYWQgdG8gcHJvYmxlbXMgdGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBh Y3R1YWxseSBldmVuIGhhdmUuJm5ic3A7IEl04oCZcyBhbHJlYWR5IGJlZW4gZXN0YWJsaXNoZWQN CiB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZvciBhIFNFVCB0byBiZSBjb25mdXNlZCBmb3IgYW4g SUQgVG9rZW4g4oCTIHNlZSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQt MkRldmVudF9jdXJyZW50X21zZzAwNDI4Lmh0bWwmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWVLTFRRUG1ZclYzVGhmRGJuOTBTQ3M1NVVST1RQ aW5fbGdjNlJkcjVYb3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRtbDwvYT4u Jm5ic3A7IElmIHBlb3BsZSBoYXZlIGRhdGEgc2hvd2luZyB0aGF0IHRoaXMgaXMgcG9zc2libGUg d2l0aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9rZW5zIG9yIG90aGVyIHJlYWwgSldUIGRl cGxveW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZpY3MsIHNvIHRoYXQgd2UgY2FuIHVzZSB0 aGF0IGRhdGEgdG8gaW5mb3JtDQogYXBwcm9wcmlhdGUgZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBv dXIgcGFydC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGUgcHJv cG9zZWQg4oCcc29sdXRpb25z4oCdLCBzdWNoIGFzIHByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCc c3Vi4oCdIGluIHRoZSBub3JtYWwgd2F5LCBvciByZXF1aXJpbmcgYSB0eXBlIGNsYWltLCB3b3Vs ZCBtYWtlIHByZXZpb3VzbHkgc2ltcGxlIHRoaW5ncyB1bm5lY2Vzc2FyaWx5DQogY29tcGxleC4m bmJzcDsgWWVzLCB0aGVuIHRoZSByZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1h bCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNv ZGUgd291bGQgaGF2ZSB0byBiZSB1c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJz ZXIuJm5ic3A7IFRoZSBtb3JlIHVud2llbGR5IHdlIG1ha2UgaXQgdG8gdXNlIFNFVHMsIHRoZSBt b3JlIGxpa2VseSBkZXZlbG9wZXJzIGFyZSB0bw0KIGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRh IHN0cnVjdHVyZXMuJm5ic3A7IEtlZXBpbmcgaXQgc2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRp b24uJm5ic3A7IFN0YW5kYXJkcyBhcmUgb25seSB1c2VmdWwgaWYgdGhleSBhcmUgYWN0dWFsbHkg dXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBJ ZC1ldmVudCBbPGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNTozMyBQTTxicj4NCjxiPlRvOjwvYj4gTWFyaXVzIFNj dXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBIZW5rIEJpcmtob2x6ICZs dDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0 PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNz IFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjog Y2FuIHlvdSBleHBsYWluIHdoYXQgeW91IG1lYW4gYnkg4oCcaW50ZW5k4oCdPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VG8geW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRl ciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRp LXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRo ZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50DQogbWF5IHJlZmVyIHRvIHdoZW4gZGV0ZXJtaW5p bmcgd2hldGhlciB0byBhY2NlcHQgYSBKV1QgYmVpbmcgcHJlc2VudGVkIHRvIGl0IGluIHNvbWUg Y29udGV4dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLSZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklkZW50aXR5IFNlcnZp Y2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj5Gcm9tOg0KPC9iPklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6 MDUgQU08YnI+DQo8Yj5UbzogPC9iPkhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRCBFdmVudHMg TWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFu ZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgSnVuIDEzLCAyMDE3 IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmto b2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFuZCBhIDJuZCBxdWVzdGlvbi48YnI+DQo8YnI+DQpXaGF0IHNlbWFudGljcyB3b3VsZCAm cXVvdDt1c2FnZSZxdW90OyBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICZx dW90O2ludGVuZCZxdW90OywgJnF1b3Q7YXVkaWVuY2UmcXVvdDssIGFuZCAmcXVvdDtzY29wZSZx dW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mcXVvdDthdWQmcXVvdDsgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRh cmdldCBjbGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8g YXV0aG9yaXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1cml0 eSBldmVudD8pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mcXVvdDtzY29wZSZxdW90OyBpcyBub3QgdXNlZCBieSBTRVQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0 IGtub3cgd2hhdCBkbyB5b3UgbWVhbiBieSAmcXVvdDtpbnRlbmQmcXVvdDsgKG9yIGludGVudCk/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxi cj4NCkhlbms8YnI+DQo8YnI+DQpPbiAwNi8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFu a3MgZm9yIHB1dHRpbmcgdGhpcyB0b2dldGhlciE8YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSBhc3N1 bXB0aW9ucyBpbmhlcmVudCBpbiAzLjkgYXJlIGZsYXdlZDo8YnI+DQo8YnI+DQrCt1dlIGNhbuKA mXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkg ZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBh bmQgZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBj bGFpbeKAnSBhcHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3Bl YyBjYW7igJl0IGJlIG1pc3Rha2VuIGZvciBKV1RzDQogZnJvbSBhIGN1cnJlbnQgc3BlYy48YnI+ DQo8YnI+DQrCt0l0IGlzIHVucmVhbGlzdGljIHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRo ZXJlIHRvIHRoZSDigJxkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPi gJ0gcnVsZS4gV2hldGhlciBtYW5kYXRlZCBieSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVy cyB3aWxsIGlnbm9yZSB0aGlzIGJlY2F1c2UgbWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhh biBtYW5hZ2luZyBOIGRpZmZlcmVudCBrZXlzLjxicj4NCjxicj4NCsK3RGl0dG8gZm9yIOKAnGF1 ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy48YnI+DQo8YnI+DQomIzQzOzEgZm9yIGEg4oCcdHlw ZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1ldGVyLjxicj4NCjxicj4NCi0t IDxicj4NCjxicj4NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48YnI+DQo8YnI+DQpJZGVudGl0 eSBTZXJ2aWNlczxicj4NCjxicj4NCipGcm9tOiAqSWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0 bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBocmVm PSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0 QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KKkRhdGU6ICpNb25kYXksIEp1bmUgMTIsIDIwMTcgYXQg MzoxOCBQTTxicj4NCipUbzogKk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzpt c2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5j b208L2E+Jmd0Ozxicj4NCipDYzogKkFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3 ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDss ICZxdW90O21hdGFrZSwgbm92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5q cCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxp bmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDtQaGlsIEh1bnQgKElETSkm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQoqU3ViamVjdDogKlJlOiBb SWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0 aW5jdCBTRVQgaXNzdWVyPGJyPg0KPGJyPg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3Rp bGwgbG90cyBvZiBkaXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS48YnI+DQo8YnI+ DQpPbiBNb24sIEp1biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8 YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNj dXJ0ZXNjdUBnb29nbGUuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+ Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHRoZSBw b2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICZxdW90OzIuNy4gQ3Jvc3MtSldUIENvbmZ1c2lv biZxdW90OyBhbmQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBtaXRpZ2F0aW9uIGlzIGluICZxdW90 OzMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2ZSBWYWxpZGF0aW9uIFJ1bGVzIGZvcjxicj4NCiZu YnNwOyAmbmJzcDsgRGlmZmVyZW50IEtpbmRzIG9mIEpXVHMmcXVvdDssIHNwZWNpZmljYWxseSAm cXVvdDtVc2UgZGlmZmVyZW50IHNldHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IHJlcXVpcmVkIGNs YWltcy4uLiZxdW90OywgJnF1b3Q7VXNlIGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2lu ZHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IEpXVHMuJnF1b3Q7IGFuZCAmcXVvdDtVc2UgZGlmZmVy ZW50IGlzc3VlcnMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzLiZxdW90Oy48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IEkgc3RpbGwgdGhpbmsgdGhhdCBhICZxdW90O3R5cGUmcXVvdDsgY2xh aW0gd291bGQgYnJpbmcgYSBsb3Qgb2YgY2xhcml0eSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IHNh ZmV0eS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE1hcml1czxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjU5IFBNLCBEaWNrIEhhcmR0ICZs dDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5k aWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5o YXJkdEBnbWFpbC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFlhcm9uLCBNaWtlIGFuZCBJIGp1c3QgcHVibGlzaGVkIGFuIEJDUCBJ RCBmb3IgSldUPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zZWxmLTJEaXNz dWVkLmluZm9fLTNGcC0zRDE2OTAmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAw WV8zelJvYWkxMTVjJmFtcDtzPWE3WHZaNWpUYnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpN Y1VJVVEmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/ cD0xNjkwPC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUs IEp1biA4LCAyMDE3IGF0IDk6MDIgUE0gQWRhbSBEYXdlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFk YXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+ Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgSSB3YXMgaW5pdGlhbGx5IGEgZmFuIG9mIGtlZXBpbmcgU0VUUyB0byBiZSB2 ZXJ5IHNpbWlsYXIgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBpZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUs IEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgJmx0OzxhIGhyZWY9Im1haWx0bzpu b3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwvYT48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwvYT4m Z3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7MSBlc3BlY2lhbGx5IGZvciAmcXVvdDt0eXBl JnF1b3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAyMDE3LTA2LTA5IDEwOjMyIEdNVCYjNDM7MDk6MDAgUGhpbCBIdW50 IChJRE0pPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+Jmd0OyZndDs6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7MTxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBQaGlsPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgT24gSnVuIDgsIDIwMTcsIGF0IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3U8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoZXJlIHdlcmUg YSBjb3VwbGUgb2YgcHJvcG9zYWxzIG9uIGhvdyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkaXN0aW5n dWlzaCBTRVRzIGZyb20gSWQgVG9rZW5zIGFuZCBBY2Nlc3MgVG9rZW5zIGluPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHN1Y2ggYSB3YXkgdGhhdCBuYWl2ZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3Q8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY29uZnVzZSBvbmUgZm9yIHRoZSBvdGhlciBhbmQgb3BlbiB1cCBzZWN1 cml0eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2dWxuZXJhYmlsaXRpZXMuPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSBpcyBhbHNvIGFu b3RoZXIgaW1wb3J0YW50IHJlcXVpcmVtZW50OiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0VUIGlz c3VlciBpbiBzb21lIGNhc2VzIG11c3QgYmUgZGlmZmVyZW50IGZyb20gdGhlPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZxdW90O3N1YiZxdW90OyBpc3N1ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAg c2VuZGluZyBTRVRzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGFuIElkUC48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFdpdGggdGhlc2UgcmVx dWlyZW1lbnRzIGluIG1pbmQgSSBwcm9wb3NlIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb2xsb3dp bmc6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSBib3RoICZxdW90O3N1YiZxdW90OyBh bmQgJnF1b3Q7aXNzJnF1b3Q7IHRvIGJlIGRlZmluZWQgYXQgdGhlIGV2ZW50PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGxldmVsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSAmcXVvdDtpc3MmcXVv dDsgYXQgZXZlbnQgbGV2ZWwgYW5kIGF0IHRvcCBTRVQgbGV2ZWwgY2FuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGJlIGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNz JnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDsgYXQgZXZlbnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVu dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBhY3Jvc3MgZXZlbnRzIGluIHRoZSBzYW1lIFNFVDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7c3ViJnF1b3Q7IHNob3VsZCBOT1QgYmUgcHJl c2VudCBhdCB0aGUgdG9wIFNFVDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZXZlbCAodGhpcyBzb2x2ZXMg dGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7 c2hvdWxkJnF1b3Q7IGFuZCBub3QgJnF1b3Q7bXVzdCZxdW90Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhpcyBzb2x1dGlvbiBhbHNv IGFsbG93cyBkaWZmZXJlbnQgcHJvZmlsZXMgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWZpbmUg ZXZlbnQgdHlwZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xhaW1zPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHJlbGF0ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2 ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmln dWl0eS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IEFub3RoZXIgcHJvcG9zYWwgKHdoaWNoIEkgc3VwcG9ydGVkKSB3YXMgdG88YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgZGVmaW5lIGEgY29tcG9zaXRlICZxdW90O2F1ZCZxdW90OyBjbGFpbS4gVGhp cyBpcyBub3Qgc29sdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgcmVxdWlyZW1lbnQgZm9yIGEg ZGlzdGluY3QmbmJzcDsgU0VUIGlzc3Vlci4gQWxzbyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaGF2aW5n IHRoZSBzYW1lIGNsYWltIG5hbWUgaGF2aW5nIGRpZmZlcmVudCBzeW50YXg8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgaW4gZGlmZmVyZW50IHRva2VuIHR5cGVzIGNvdWxkIGxlYWQgdG8gY29uZnVzaW9uLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg QW5kIHlldCBhbm90aGVyIHByb3Bvc2FsIHdhcyB0byBpbnRyb2R1Y2UgYSBuZXc8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgY2xhaW0gZm9yIEpXVHMgdGhhdCBkZWZpbmVzIGEgJnF1b3Q7dHlwZSZxdW90Oy4g VGhpcyBpcyBub3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJt LCBhbmQgaXQgYWxzbyBpcyBub3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc29sdmluZyB0aGUgZGlzdGlu Y3QgaXNzdWVyIHJlcXVpcmVtZW50LCBidXQgSSB0aGluazxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlz IGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNob3VsZCBzZXJpb3VzbHk8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgY29uc2lkZXIuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyBUaG91Z2h0cz88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IE1hcml1czxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0Ow0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUptdXV0Qng0REFQ cDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1wO3M9NXhRcXZCaVhaNklqOU5HRHdW cVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gy SV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1wO3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZ S09DZDBteFBRRkpMaHhXSSZhbXA7ZT08L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBL SHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5 dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZl bnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtz PVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFk YW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHw8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUu Y29tPC9hPiZndDsgfDxhIGhyZWY9InRlbDolMkIxJTIwNjUwLTIxNC0yNDEwIiB0YXJnZXQ9Il9i bGFuayI+JiM0MzsxIDY1MC0yMTQtMjQxMDwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0idGVsOiUyODY1MCUyOSUyMDIxNC0yNDEw IiB0YXJnZXQ9Il9ibGFuayI+dGVsOig2NTApJTIwMjE0LTI0MTA8L2E+Jmd0Ozxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1w O3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tIDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSAm bHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4 UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZhbXA7cz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1Z QmVyVjgwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvYT4m Z3Q7DQogbWFpbCBsaXN0IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYXJu IGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQot LSA8YnI+DQo8YnI+DQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2Fy ZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZh bXA7cz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvYT4mZ3Q7DQogbWFpbCBsaXN0 IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBL SHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5 dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K SWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2ht UWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xE NEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJ Q0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1w O3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xq N0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tG WllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2ht UWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xE NEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPTwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3By ZT4NCjxwcmU+SWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRA aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C35BA428D6814782982A92A20CB4B614amazoncom_-- From nobody Mon Jun 19 14:55:35 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D083126CE8 for ; Mon, 19 Jun 2017 14:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN5hlEhxD9jW for ; Mon, 19 Jun 2017 14:55:28 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FA0129521 for ; Mon, 19 Jun 2017 14:55:28 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m62so3567544itc.0 for ; Mon, 19 Jun 2017 14:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h/FZuObfllkPyXE5j7TJq1EuvBjpAJWuKan0BV7ndUY=; b=YwrOar3ZpT3FK+cqMO7udavwaAvQhN5/XLQ0Bciox5jBJZ2GcjH0kcp7PKLtDaEwXi RjJUj/VHYCaC/Sjwp65wJxBQpiGjoxM4vC9/3GE06vuzBWrIXIbmnZSqm2ggsOynPWVo 9iPtLxihlF4iXeHC4cXUxqeFboy/pjwysT+48lZy/elpvS7NErd6rnMc25iSvht6WRRN WcS54EnUuOR76nBLnXcThKhEkJUiWog3yavbArOKU6Mtuk3TXRNfNePN2LLxUWZIOOnX Jd3nZQVNo/wbTdzY+hVCQ7Oz8n7ZXo2r2JxsB9Aof5VA25bCpPkWYC5HZc3oJMeyyNZH TIEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h/FZuObfllkPyXE5j7TJq1EuvBjpAJWuKan0BV7ndUY=; b=H+NfUgneOlTAKJ8wQLb8grmLz4BZcG2QTdYuGEJKYp96YNrVa0v2PJi5wW65JOKRpb U6wco29Rs8DcdkcevVcLdepuSbbv8+FJ2jjhZqaCe/Bd83qph9luQLQ4C08hUK9xfyLk WkHuhlOuE83peePXW+bLjAGUwQp2DKVggRX80nZNH4yXBOwB3PpE0JEejvKumnKsC2xM zLp/KgD9SeNZoF+WA5Fso7aoPZcBXJuEAblsoBhobPV8003lnVShrC1TuqfDh1GkBi/9 16XWgezwbDm8gDeBJzBJ77QJYO0DLJfij01p+JkTYF/j2OGYLwVQheGk3ifeyyFR1kB2 TioA== X-Gm-Message-State: AKS2vOxltzYx6hOuqzf+1SglEQy6fZvEqEXhz3vrhkezCTLNemBGUOoo T2181seb1o9MbItB8B/HPS4/vyGRpla+ X-Received: by 10.36.172.84 with SMTP id m20mr757227iti.119.1497909327121; Mon, 19 Jun 2017 14:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.36 with HTTP; Mon, 19 Jun 2017 14:55:06 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> From: Marius Scurtescu Date: Mon, 19 Jun 2017 14:55:06 -0700 Message-ID: To: Mike Jones Cc: Yaron Sheffer , Justin Richer , "Richard Backman, Annabelle" , Henk Birkholz , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="94eb2c1fcbbc59d54b0552573163" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 21:55:34 -0000 --94eb2c1fcbbc59d54b0552573163 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mike, are you suggesting we define SETs in such a way that they will not work for RISC? A top level iss+sub is clearly not working for RISC, and may not work for logout either if you allow logout to be initiated from an RP. Marius On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones wrote: > Marius, there=E2=80=99s nothing stopping you (or the RISC working group o= r other > profiles) from defining events that can be sent from RPs to IdPs now, > without any changes to the SET spec. Specify the claims you want to use, > and you=E2=80=99re golden. > > > > But it would be counterproductive to require all other SETs to meet the > requirements of your specific profile. There are simpler use cases that > can use claims in simpler ways. Trying to make the simple use cases be > complex will have the side effect of limiting the adoption of the spec, > which wouldn=E2=80=99t be good for anyone. > > > > If successful, SETs will have many different profiles. That=E2=80=99s a = sign of > success =E2=80=93 not a sign of weakness. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Monday, June 19, 2017 11:58 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Justin Richer < > jricher@mit.edu>; Richard Backman, Annabelle ; Henk > Birkholz ; ID Events Mailing List < > id-event@ietf.org>; Phil Hunt > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones > wrote: > > I=E2=80=99m sorry to be slow replying to some messages in this thread. I= have a > lot of other things on my plate, but I will take the time now to reply, > because I wholeheartedly disagree with some of the statements below and > believe it would be severely harmful to the specification and its adoptio= n > to act upon them. Specifically: > > > > - I disagree that specific rules should be made for the =E2=80=9Csub= =E2=80=9D claim. > Claims usage needs to be up to the application. I know that many othe= rs > agree with me, because the OpenID Connect working group designed the l= ogout > token in http://openid.net/specs/openid-connect-backchannel-1_ > 0-04.html#LogoutToken (which is also used as an example in > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 > ) > to use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibiting= this usage would be > a completely unnecessary breaking change =E2=80=93 as it=E2=80=99s imp= ossible to confuse a > logout token with an ID Token, for reasons already cites in this threa= d. > > Solving the confusion is one problem. The other problem I keep mentioning > is SETs issued by an RP to be sent to an IdP. How are we solving that > problem Mike? In this case the top level iss is different from the iss of > the sub, a top level sub is not possible. > > > > And I don't want to downplay the confusion problem either. I think it is = a > real concern and I think a solid solution is important. > > > > The OpenID Working Group designed logout tokens without secevent in mind. > I agree we should not recklessly break compatibility, but to me it seems > necessary in this case. > > > > > - > > > > - (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 > = . > No further =E2=80=9Ciss=E2=80=9D rules are needed.) > > > > Further iss ruies are absolutely needed for the RP to IdP case described > above. > > > > > > > - > > > > - It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to = be used for some > profiles to differentiate between kinds of JWTs. Its use should not b= e > mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D > functionality by defining another claim with a duplicative meaning. > > If typ can be use and no other claim is needed, then let's talk about > that. I do think SET should mandate it. I don't understand why not. Can y= ou > please propose with examples how can typ be used? > > > > > > > - > > > > - I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of > JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D This reflects a > misunderstanding. It=E2=80=99s the **value** of the nonce that self-s= ecures > the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is presen= t. Any and all JWTs can > simultaneously use =E2=80=9Cnonce=E2=80=9D without any risk of conflic= t, since the nonce > value is a cryptographically secure random number. > > > > For SETs I cannot see how the nonce value is useful. That value is not > passed back and it cannot be verified. Only the presence of the claim cou= ld > have some use, hinting at the usage of the JWT, a very weak solution to t= he > confusion problem. > > > > > - > > > > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d = be glad > to have in-person discussions about these topics there. > > > > -- Mike > > > > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or= any other claim) > or forcing it to be located in a non-standard location makes about as muc= h > sense as arbitrarily saying that, for a particular profile, the Latin wor= d > for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name in= stead of =E2=80=9Csub=E2=80=9D. > Yes, it will completely differentiate this profile from others not spelli= ng > the claim name this way, but it would certainly be an impediment to the u= se > of standard JWT libraries and to interoperability. > > > > If we define that sub must be at the event level then it is at a standard > location, I don't see what the issue is. The impediment you mention is th= e > actual solution. I don't think that a JWT library that was written for Id > Tokens should be used to parse SETs. The library has to be SET aware, in > which case the event level iss+sub is not an issue at all. > > > > > > > > > > *From:* Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > *Sent:* Saturday, June 17, 2017 1:45 PM > *To:* Justin Richer ; Marius Scurtescu < > mscurtescu@google.com> > *Cc:* Richard Backman, Annabelle ; Mike Jones < > Michael.Jones@microsoft.com>; Henk Birkholz de>; ID Events Mailing List ; Phil Hunt < > phil.hunt@oracle.com> > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id- > 2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > > --94eb2c1fcbbc59d54b0552573163 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike, are you suggesting we define SETs in such a way that= they will not work for RISC? A top level iss+sub is clearly not working fo= r RISC, and may not work for logout either if you allow logout to be initia= ted from an RP.

Marius
<= /div>
On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Marius, there=E2=80=99= s nothing stopping you (or the RISC working group or other profiles) from d= efining events that can be sent from RPs to IdPs now, without any changes t= o the SET spec.=C2=A0 Specify the claims you want to use, and you=E2=80=99re golden.

=C2=A0

But it would be counte= rproductive to require all other SETs to meet the requirements of your spec= ific profile.=C2=A0 There are simpler use cases that can use claims in simp= ler ways.=C2=A0 Trying to make the simple use cases be complex will have the side effect of limiting the adoption of the= spec, which wouldn=E2=80=99t be good for anyone.

=C2=A0

If successful, SETs wi= ll have many different profiles.=C2=A0 That=E2=80=99s a sign of success =E2= =80=93 not a sign of weakness.

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Justin Richer <jricher@mit.edu>; Richard Ba= ckman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com><= /p>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I=E2=80=99m sorry to b= e slow replying to some messages in this thread.=C2=A0 I have a lot of othe= r things on my plate, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it= would be severely harmful to the specification and its adoption to act upo= n them.=C2=A0 Specifically:

=C2=A0

Solving the confusion is one problem. The other prob= lem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are= we solving that problem Mike? In this case the top level iss is different = from the iss of the sub, a top level sub is not possible.

=C2=A0

And I don't want to downplay the confusion probl= em either. I think it is a real concern and I think a solid solution is imp= ortant.

=C2=A0

The OpenID Working Group designed logout tokens with= out secevent in mind. I agree we should not recklessly break compatibility,= but to me it seems necessary in this case.

=C2=A0

  • =C2=A0

=C2=A0

=C2=A0

Further iss ruies are absolutely needed for the RP t= o IdP case described above.

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used= for some profiles to differentiate between kinds of JWTs.=C2=A0 Its use sh= ould not be mandated in the SET spec.=C2=A0 I would oppose duplicating the = =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a duplic= ative meaning.

If typ can be use and no other claim is needed, then= let's talk about that. I do think SET should mandate it. I don't u= nderstand why not. Can you please propose with examples how can typ be used= ?

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other profile of JWT can ever use the "no= nce=E2=80=9D claim.=E2=80=9D=C2=A0 This reflects a misunderstanding.= =C2=A0 It=E2=80=99s the *value* of the nonce that self-secures the J= WT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is present.=C2=A0 Any and all JWTs can simultaneously use =E2=80=9Cn= once=E2=80=9D without any risk of conflict, since the nonce value is a cryp= tographically secure random number.

=C2=A0

For SETs I cannot see how the nonce value is useful.= That value is not passed back and it cannot be verified. Only the presence= of the claim could have some use, hinting at the usage of the JWT, a very = weak solution to the confusion problem.

=C2=A0

  • =C2=A0

=C2=A0

Will some of you be at= the Cloud Identity Summit next week?=C2=A0 I=E2=80=99d be glad to have in-= person discussions about these topics there.

=C2=A0

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

=C2=A0

P.S.=C2=A0 Food for th= ought:=C2=A0 Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any other cla= im) or forcing it to be located in a non-standard location makes about as m= uch sense as arbitrarily saying that, for a particular profile, the Latin word= for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name ins= tead of =E2=80=9Csub=E2=80=9D.=C2=A0 Yes, it will completely differentiate = this profile from others not spelling the claim name this way, but it would certainly be an impediment to the use of standard JWT libraries and = to interoperability.

=C2=A0

If we define that sub must be at the event level the= n it is at a standard location, I don't see what the issue is. The impe= diment you mention is the actual solution. I don't think that a JWT lib= rary that was written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case the = event level iss+sub is not an issue at all.

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= u>

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscurtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@mic= rosoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>= ;; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com><= /p>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules f= or "sub" and "iss" that can be defined in the SET spec.=

Almost everybody agrees on a long-term "usage" claim ("ty= pe" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use = it in the SET document before it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.= com> wrote:

=C2=A0

+1 to what Annabelle said.

=C2=A0

Also, Mike you are missing the other requirement, fo= r RPs to send events to an IdP. The iss+sub pair at the top level is broken= in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <= ;phil.hunt@oracle= .com> wrote:

+1

=C2=A0

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote= :

Mike,

=C2=A0

Your explanation for why this is a non-problem is de= pendent upon side effects of elements of OpenID Connect that were not desig= ned to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certa= in that a nonce-less ID Token is really an ID Token. Any party that the cal= ler passes the ID Token off to has no way to verify its provenance.<= u>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem = again.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim.=

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that = cares about disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and r= eplay attacks are both things that happen. What=E2=80=99s being proposed is= a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use commo= n libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library co= uld handle disambiguation for any JWT profile, whereas with the status quo = each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@mic= rosoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events = Mailing List <id-= event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

You=E2=80=99ve heard o= f =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d characterize = the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2= =80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0

Mandatory solutions ar= e being proposed in this thread to problems that there=E2=80=99s no evidenc= e that we actually even have.=C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.h= tml.=C2=A0 If people have data showing that this is possible with speci= fic kinds of Access Tokens or other real JWT deployments, please provide sp= ecifics, so that we can use that data to inform appropriate engineering choices on our part.

=C2=A0

The proposed =E2=80=9C= solutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80=9D in= the normal way, or requiring a type claim, would make previously simple th= ings unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org= ] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain w= hat you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better analogy wou= ld be the X.509 Key Usage extension: a multi-valued property that declares = the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to i= t in some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.= com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank">henk.bi= rkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target clie= nt, but not the intended usage (access token to authorize resource access o= r SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.<= /p>

=C2=A0

I don't know what do you mean by "intend&qu= ot; (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com<= /a>>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing Li= st <id-event@ietf= .org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:= mscurtescu@googl= e.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank">adawes@google.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake= .jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com <mai= lto:phil.hunt@ora= cle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank">mscurtescu@google= .com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:mscurtescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-event@ietf.org <mailto:Id-even= t@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxP= EivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6mi= RiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&a= mp;e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <= ;mailto:Id-event@iet= f.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtw= are.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

=C2=A0



_______________________________________________

Id-event mailing list


Id-event@ietf.o=
rg


https://www.ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0


--94eb2c1fcbbc59d54b0552573163-- From nobody Wed Jun 21 11:48:03 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534F7129478 for ; Wed, 21 Jun 2017 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=openconsentgroup.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaAP0XR_kzn6 for ; Wed, 21 Jun 2017 11:47:57 -0700 (PDT) Received: from n1nlsmtp03.shr.prod.ams1.secureserver.net (n1nlsmtp03.shr.prod.ams1.secureserver.net [188.121.43.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95804128B44 for ; Wed, 21 Jun 2017 11:47:56 -0700 (PDT) Received: from n1plcpnl0072.prod.ams1.secureserver.net ([188.121.57.6]) by : HOSTING RELAY : with SMTP id NkeUdiIxHPVhdNkeUdyYt5; Wed, 21 Jun 2017 11:46:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openconsentgroup.com; s=default; h=References:To:Cc:In-Reply-To:Date: Subject:Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JKFayy2CrAJCQzKSvwRVW1IA5CNxcU74wy0m1dcpriU=; b=YZMZM0tc8ptviCJnvil+JubOF 2ltw+dIRSxFGf5F9ONzhyXTrYYL6vMlLGEyM5LbeAr1wgRKHPK1Lv2ertHZkvDvW3OEkWDcfYyslZ BIxBSpU+eRNr2yZbUGnBzLwSpYXyNQRtddrbxBvRR22oqtON8Iz4oq5ar3wTrANxJ6hA9s92r/sP1 579JsbjtBGk2xPTredTWNVeqnhi2GS782OfM5QVdrJtFObzM2b+SZWx132bqI2urETRK7mVJh4NA0 2w1+zsFUq7Tlu8kgkBUuvwHG79Asmy0jBplajBslusOguUi338nUkMCmJxO9yUGaekozRurtTh2Ra 0N6c3JLiw==; Received: from h198.196.135.40.static.ip.windstream.net ([40.135.196.198]:59724 helo=[10.0.3.34]) by n1plcpnl0072.prod.ams1.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1dNkeR-003gPX-NG; Wed, 21 Jun 2017 11:46:53 -0700 From: "M.Lizar@OCG" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FA12085D-D0D4-476E-AD67-AD2B77042A92" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 21 Jun 2017 13:46:42 -0500 In-Reply-To: Cc: Mike Jones , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List , Phil Hunt To: Marius Scurtescu References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> X-Mailer: Apple Mail (2.3273) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n1plcpnl0072.prod.ams1.secureserver.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openconsentgroup.com X-Get-Message-Sender-Via: n1plcpnl0072.prod.ams1.secureserver.net: authenticated_id: m.lizar@openconsentgroup.com X-Authenticated-Sender: n1plcpnl0072.prod.ams1.secureserver.net: m.lizar@openconsentgroup.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfA9bp9YsYVYD4+4l27j2sJBvxhzgKbRPnFdAJ2MZGxMz+brD5hyV2YR0N19jJjIF+q6aPQcMysNZI7gy5XieCzHE1nZPmYmN7QuFOYJRegRgzOHXlJOl XivSupLPwwZz3v72wx/1xzSkjcv2OSYjxNcdOor5vTKnpFDd49KaGHvOLP4XU7S/ziiuFBJ6yvSe5eJ+FpBRmnek5uzYAmHbM2A= Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:48:01 -0000 --Apple-Mail=_FA12085D-D0D4-476E-AD67-AD2B77042A92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW - I agree with Mike that putting restrictions on the "sub" claim = usage would unnecessarily complicate SETs for some use cases. Its a lot easier to add to a spec and very difficult (if not impossible) = to retract. In this regard, keeping it simple is critical for broad = adoption.=20 Mark > On 19 Jun 2017, at 16:55, Marius Scurtescu = wrote: >=20 > Mike, are you suggesting we define SETs in such a way that they will = not work for RISC? A top level iss+sub is clearly not working for RISC, = and may not work for logout either if you allow logout to be initiated = from an RP. >=20 > Marius >=20 > On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones = > = wrote: > Marius, there=E2=80=99s nothing stopping you (or the RISC working = group or other profiles) from defining events that can be sent from RPs = to IdPs now, without any changes to the SET spec. Specify the claims = you want to use, and you=E2=80=99re golden. >=20 > =20 >=20 > But it would be counterproductive to require all other SETs to meet = the requirements of your specific profile. There are simpler use cases = that can use claims in simpler ways. Trying to make the simple use = cases be complex will have the side effect of limiting the adoption of = the spec, which wouldn=E2=80=99t be good for anyone. >=20 > =20 >=20 > If successful, SETs will have many different profiles. That=E2=80=99s = a sign of success =E2=80=93 not a sign of weakness. >=20 > =20 >=20 > -- Mike >=20 > =C2=A0 <> > From: Marius Scurtescu [mailto:mscurtescu@google.com = ]=20 > Sent: Monday, June 19, 2017 11:58 AM > To: Mike Jones > > Cc: Yaron Sheffer >; Justin Richer >; Richard Backman, Annabelle = >; Henk Birkholz = >; ID Events Mailing List = >; Phil Hunt = > >=20 >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones = > = wrote: >=20 > I=E2=80=99m sorry to be slow replying to some messages in this thread. = I have a lot of other things on my plate, but I will take the time now = to reply, because I wholeheartedly disagree with some of the statements = below and believe it would be severely harmful to the specification and = its adoption to act upon them. Specifically: >=20 > =20 >=20 > I disagree that specific rules should be made for the =E2=80=9Csub=E2=80= =9D claim. Claims usage needs to be up to the application. I know that = many others agree with me, because the OpenID Connect working group = designed the logout token in = http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken= = (which is also used as an example = inhttps://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 = ) to = use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibiting this = usage would be a completely unnecessary breaking change =E2=80=93 as = it=E2=80=99s impossible to confuse a logout token with an ID Token, for = reasons already cites in this thread. > Solving the confusion is one problem. The other problem I keep = mentioning is SETs issued by an RP to be sent to an IdP. How are we = solving that problem Mike? In this case the top level iss is different = from the iss of the sub, a top level sub is not possible. >=20 > =20 >=20 > And I don't want to downplay the confusion problem either. I think it = is a real concern and I think a solid solution is important. >=20 > =20 >=20 > The OpenID Working Group designed logout tokens without secevent in = mind. I agree we should not recklessly break compatibility, but to me it = seems necessary in this case. >=20 > =20 >=20 > =20 > =20 >=20 > (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at = https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 = . = No further =E2=80=9Ciss=E2=80=9D rules are needed.) > =20 >=20 > Further iss ruies are absolutely needed for the RP to IdP case = described above. >=20 > =20 >=20 > =20 >=20 > =20 > =20 >=20 > It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be = used for some profiles to differentiate between kinds of JWTs. Its use = should not be mandated in the SET spec. I would oppose duplicating the = =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a = duplicative meaning. > If typ can be use and no other claim is needed, then let's talk about = that. I do think SET should mandate it. I don't understand why not. Can = you please propose with examples how can typ be used? >=20 > =20 >=20 > =20 >=20 > =20 > =20 >=20 > I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9C= No other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D = This reflects a misunderstanding. It=E2=80=99s the *value* of the = nonce that self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80= =9D claim is present. Any and all JWTs can simultaneously use = =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a cryptographically secure random number. > =20 >=20 > For SETs I cannot see how the nonce value is useful. That value is not = passed back and it cannot be verified. Only the presence of the claim = could have some use, hinting at the usage of the JWT, a very weak = solution to the confusion problem. >=20 > =20 >=20 > =20 > =20 >=20 > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d= be glad to have in-person discussions about these topics there. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D = (or any other claim) or forcing it to be located in a non-standard = location makes about as much sense as arbitrarily saying that, for a = particular profile, the Latin word for subject =E2=80=9Csubiectum=E2=80=9D= must be used as the claim name instead of =E2=80=9Csub=E2=80=9D. Yes, = it will completely differentiate this profile from others not spelling = the claim name this way, but it would certainly be an impediment to the = use of standard JWT libraries and to interoperability. >=20 > =20 >=20 > If we define that sub must be at the event level then it is at a = standard location, I don't see what the issue is. The impediment you = mention is the actual solution. I don't think that a JWT library that = was written for Id Tokens should be used to parse SETs. The library has = to be SET aware, in which case the event level iss+sub is not an issue = at all. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =C2=A0 <> > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com = ]=20 > Sent: Saturday, June 17, 2017 1:45 PM > To: Justin Richer >; Marius = Scurtescu > > Cc: Richard Backman, Annabelle >; Mike Jones >; Henk Birkholz = >; ID Events Mailing List = >; Phil Hunt = > >=20 >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > So to summarize what I'm seeing on this thread: >=20 > Everybody agrees with Marius's short-term solution, specific rules for = "sub" and "iss" that can be defined in the SET spec. >=20 > Almost everybody agrees on a long-term "usage" claim ("type" is taken) = that should be defined elsewhere, e.g. in the JWT BCP. >=20 > Did I miss anything? >=20 > By the way, if we do add a "usage" claim, we need to also use it in = the SET document before it is published. >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > On 15/06/17 22:08, Justin Richer wrote: >=20 > +1 to this as well. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > =20 >=20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: >=20 > =20 >=20 > +1 to what Annabelle said. >=20 > =20 >=20 > Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >=20 >=20 >=20 > Marius >=20 > =20 >=20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: >=20 > +1 >=20 > =20 >=20 > Phil >=20 >=20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >=20 > Mike, >=20 > =20 >=20 > Your explanation for why this is a non-problem is dependent upon side = effects of elements of OpenID Connect that were not designed to solve = this issue. As a result, I see several issues with it: >=20 > 1. The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance. >=20 > 2. Any future ID Token distribution method needs to solve this = problem again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile = that cares about disambiguation has to invent its own solution to the = problem. >=20 > =20 >=20 > We know from experience that naming collisions and replay attacks are = both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. >=20 > =20 >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > =20 >=20 > =20 >=20 > From: Id-event > on behalf of Mike Jones = > > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > > Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematur= e pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >=20 > =20 >=20 > Mandatory solutions are being proposed in this thread to problems that = there=E2=80=99s no evidence that we actually even have. It=E2=80=99s = already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 = seehttps://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >=20 > =20 >=20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use = of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, = would make previously simple things unnecessarily complex. Yes, then = the result is then different than a normal JWT but a consequence of this = is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu >; Henk Birkholz = > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > Echoing Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D? >=20 > =20 >=20 > To your first question, I think a better analogy would be the X.509 = Key Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context. >=20 > =20 >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > =20 >=20 > =20 >=20 > From: Id-event > on behalf of Marius Scurtescu = > > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > =20 >=20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >=20 > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"? >=20 > =20 >=20 > "aud" (audience) specifies the target client, but not the intended = usage (access token to authorize resource access or SET to communicate a = security event?) >=20 > =20 >=20 > "scope" is not used by SET. >=20 > =20 >=20 > I don't know what do you mean by "intend" (or intent)? >=20 > =20 >=20 > =20 >=20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >=20 > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event > on behalf of Dick Hardt = > > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > > *Cc: *Adam Dawes >, = "matake, nov" >, ID Events Mailing = List >, "Phil Hunt (IDM)" = > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be = in 3.9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = = >> wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > >> = wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 = >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > >> wrote: >=20 > I was initially a fan of keeping SETS to be very similar = to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > >> wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > = >>: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > >> wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens = in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: = the > SET issuer in some cases must be different from = the > "sub" issuer. This is the case of an RP sending = SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the = event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be = different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please = note > "should" and not "must" > > > > This solution also allows different profiles = that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not = solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I = think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list >=20 > > Id-event@ietf.org = > > > > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com = > > |+1 = 650-214-2410 > > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Subscribe to the HARDTWARE > mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = > =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_FA12085D-D0D4-476E-AD67-AD2B77042A92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW - I = agree with Mike that putting restrictions on the "sub" claim usage would = unnecessarily complicate SETs for some use cases.

Its a lot easier to add to a spec and very difficult (if not impossible) to retract. In this = regard, keeping it simple is critical for broad = adoption. 

Mark

On 19 Jun 2017, at 16:55, Marius Scurtescu = <mscurtescu@google.com> wrote:

Mike, are you suggesting we define SETs in such a way that = they will not work for RISC? A top level iss+sub is clearly not working = for RISC, and may not work for logout either if you allow logout to be = initiated from an RP.

Marius

On Mon, Jun 19, 2017 at 2:27 = PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Marius, = there=E2=80=99s nothing stopping you (or the RISC working group or other = profiles) from defining events that can be sent from RPs to IdPs now, = without any changes to the SET spec.  Specify the claims you want to use, and you=E2=80=99re golden.

 

But it would be counterproductive to = require all other SETs to meet the requirements of your specific = profile.  There are simpler use cases that can use claims in = simpler ways.  Trying to make the simple use cases be complex will have the side effect of limiting the adoption of = the spec, which wouldn=E2=80=99t be good for anyone.

 

If successful, SETs will have many = different profiles.  That=E2=80=99s a sign of success =E2=80=93 not = a sign of weakness.

 

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

 

From: = Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Justin Richer <jricher@mit.edu>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID = Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

On Sat, Jun 17, 2017 at 2:06 PM, = Mike Jones <Michael.Jones@microsoft.com> = wrote:

I=E2=80=99m sorry to be slow replying to some messages in = this thread.  I have a lot of other things on my plate, but I will = take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe = it would be severely harmful to the specification and its adoption to = act upon them.  Specifically:

 

Solving the confusion is one = problem. The other problem I keep mentioning is SETs issued by an RP to = be sent to an IdP. How are we solving that problem Mike? In this case = the top level iss is different from the iss of the sub, a top level sub is not possible.

 

And I don't want to downplay the = confusion problem either. I think it is a real concern and I think a = solid solution is important.

 

The OpenID Working Group designed = logout tokens without secevent in mind. I agree we should not recklessly = break compatibility, but to me it seems necessary in this case.

 

  •  

 

 

Further iss ruies are absolutely = needed for the RP to IdP case described above.

 

 

  •  

 

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be = used for some profiles to differentiate between kinds of JWTs.  Its = use should not be mandated in the SET spec.  I would oppose = duplicating the =E2=80=9Ctyp=E2=80=9D functionality by defining another = claim with a duplicative meaning.

If typ can be use and no other = claim is needed, then let's talk about that. I do think SET should = mandate it. I don't understand why not. Can you please propose with = examples how can typ be used?

 

 

  •  

 

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9C<= span style=3D"" class=3D"">No other profile of JWT can ever use the = "nonce=E2=80=9D claim.=E2=80=9D  This reflects a = misunderstanding.  It=E2=80=99s the *value* of = the nonce that self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2= =80=9D claim is present.  Any and all JWTs can simultaneously use = =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a cryptographically secure random number.

 

For SETs I cannot see how the = nonce value is useful. That value is not passed back and it cannot be = verified. Only the presence of the claim could have some use, hinting at = the usage of the JWT, a very weak solution to the confusion problem.

 

  •  

 

Will some = of you be at the Cloud Identity Summit next week?  I=E2=80=99d be = glad to have in-person discussions about these topics there.

 

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

 

P.S.  = Food for thought:  Prohibiting the use of =E2=80=9Csub=E2=80=9D (or = any other claim) or forcing it to be located in a non-standard location = makes about as much sense as arbitrarily saying that, for a particular profile, the Latin = word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim = name instead of =E2=80=9Csub=E2=80=9D.  Yes, it will completely = differentiate this profile from others not spelling the claim name this = way, but it would certainly be an impediment to the use of standard JWT libraries = and to interoperability.

 

If we define that sub must be at = the event level then it is at a standard location, I don't see what the = issue is. The impediment you mention is the actual solution. I don't = think that a JWT library that was written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case = the event level iss+sub is not an issue at all.

 

 

 

 

From: = Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu = <mscurtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microsoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

So to summarize what I'm seeing on this = thread:

Everybody = agrees with Marius's short-term solution, specific rules for "sub" and = "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term = "usage" claim ("type" is taken) that should be defined elsewhere, e.g. = in the JWT BCP.

Did = I miss anything?

By = the way, if we do add a "usage" claim, we need to also use it in the SET = document before it is published.

Thanks,

    Yaron

 

On 15/06/17 22:08, Justin Richer = wrote:

+1 to this as well.

 

 =E2=80=94 Justin

 

On Jun 15, 2017, at 1:09 PM, = Marius Scurtescu <mscurtescu@google.com> wrote:

 

+1 to what Annabelle said.

 

Also, Mike you are missing the = other requirement, for RPs to send events to an IdP. The iss+sub pair at = the top level is broken in this case.


Marius

 

On Wed, Jun 14, 2017 at 5:33 PM, = Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

+1

 

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Mike,

 

Your explanation for why this = is a non-problem is dependent upon side effects of elements of OpenID = Connect that were not designed to solve this issue. As a result, I see = several issues with it:

1.       The caller of the Token Endpoint is the only party that can be = certain that a nonce-less ID Token is really an ID Token. Any party that = the caller passes the ID Token off to has no way to verify its = provenance.

2.       Any future ID Token distribution method needs to solve this = problem again.

3.      No other profile of JWT can ever use the "nonce=E2=80=9D claim.

4.      This is only a solution for ID Tokens. Every other JWT profile = that cares about disambiguation has to invent its own solution to the = problem.

 

We know from experience that naming collisions and = replay attacks are both things that happen. What=E2=80=99s being = proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use = common libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT = library could handle disambiguation for any JWT profile, whereas with = the status quo each profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity = Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf = of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
= To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

You=E2=80=99ve heard of =E2=80=9Cpremature = optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in = this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making = things that can and should be simple complex, without data showing there=E2=80=99s any need to do = so.

 

Mandatory = solutions are being proposed in this thread to problems that there=E2=80=99= s no evidence that we actually even have.  It=E2=80=99s already = been established that it=E2=80=99s impossible for a SET to be confused for an ID Token = =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part.

 

The = proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, = would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT = but a consequence of this is that custom parsing code would have to be = used, rather than a standard JWT parser.  The more unwieldy we make = it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple is the = key to adoption.  Standards are only useful if they are actually = used.

 

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

 

From: = Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

Echoing Marius=E2=80=99s = question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?

 

To your = first question, I think a better analogy would be the X.509 Key Usage = extension: a multi-valued property that declares the intended purpose of = the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented = to it in some context.

 

-- 

Annabelle Richard Backman

Identity = Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf = of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"?

=

 

"aud" (audience) specifies the = target client, but not the intended usage (access token to authorize = resource access or SET to communicate a security event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by = "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this = together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" = <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in = 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and = the
    mitigation is in "3.9. Use Mutually Exclusive Validation = Rules for
    Different Kinds of JWTs", specifically "Use different sets = of
    required claims...", "Use different keys for different = kinds of
    JWTs." and "Use different issuers for different kinds of = JWTs.".

    I still think that a "type" claim would bring a lot of = clarity and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID = for JWT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes = <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I was initially a fan of = keeping SETS to be very similar to
            id tokens but I now think this = is a better plan.

            On Thu, Jun 8, 2017 at 6:56 PM = matake, nov <nov@matake.jp
            <mailto:nov@matake.jp>> wrote:

                +1 especially = for "type"

                2017-06-09 10:32 = GMT+09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>:

                    = +1

                    = Phil


                    =  > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    = <mscurtescu@google.com

        =             <mailto:mscurtescu@google.com>> wrote:
                    =  >
                    =  > There were a couple of proposals on how to
                    = distinguish SETs from Id Tokens and Access Tokens in
                    = such a way that naive implementations will not
                    = confuse one for the other and open up security
                    = vulnerabilities.
                    =  >
                    =  > There is also another important requirement: the
=                     = SET issuer in some cases must be different from the
                    = "sub" issuer. This is the case of an RP sending SETs
                    to = an IdP.
                    =  >
                    =  > With these requirements in mind I propose the
                    = following:
                    =  > - both "sub" and "iss" to be defined at the event
                    = level
                    =  > - "iss" at event level and at top SET level can
                    be = different
                    =  > - "iss" and "sub" at event level can be different
                    = across events in the same SET
                    =  > - "sub" should NOT be present at the top SET
                    = level (this solves the disambiguation), please note
                    = "should" and not "must"
                    =  >
                    =  > This solution also allows different profiles that
                    = define event types to define additional claims
                    = related to sub (like email or phone_number) and
                    = since all these claims will be at the event level
                    = there will be no collisions or ambiguity.
                    =  >
                    =  > Another proposal (which I supported) was to
                    = define a composite "aud" claim. This is not solving
                    = the requirement for a distinct  SET issuer. Also,
                    = having the same claim name having different syntax
                    in = different token types could lead to confusion.
                    =  >
                    =  > And yet another proposal was to introduce a new
                    = claim for JWTs that defines a "type". This is not
                    = practical in the short term, and it also is not
                    = solving the distinct issuer requirement, but I think
                    = this is something the JWT group should seriously
                    = consider.
                    =  >
                    =  > Thoughts?
                    =  >
                    =  > Marius

                    =  > _______________________________________________
                    =  > Id-event mailing list

  =                   =  > Id-event@ietf.org <mailto:Id-event@ietf.org>
                    =  >
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                    = _______________________________________________
                    = Id-event mailing list
                    Id-event@ietf.org <mailto:Id-event@ietf.org>
                    https://www.ietf.org/mailman/listinfo/id-event

                = _______________________________________________
                Id-event mailing = list
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product = Manager |adawes@google.com
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            = _______________________________________________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 



_______________________________________________
Id-event mailing list
Id-event@ietf.org
= 
https://www.ietf.org/mailman/listinfo/id-event
=

 

 


_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_FA12085D-D0D4-476E-AD67-AD2B77042A92-- From nobody Wed Jun 21 11:53:38 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB3129489 for ; Wed, 21 Jun 2017 11:53:36 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-2XZ1t3YLrS for ; Wed, 21 Jun 2017 11:53:31 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3246512947D for ; Wed, 21 Jun 2017 11:53:31 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id c201so9387397ioe.1 for ; Wed, 21 Jun 2017 11:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h72ifJ+7tHEcaNV/1J9doeqDVxjtwj2qyJWIRUQqoxI=; b=Liz/BFT+KbgT7T5fRVttP7J92kg3BbDDO8CBRitVSYtw+496PCW/sWCt8X210zSYp+ iqhNQh1JKTcD3DA5dQws8pNFS9DS03Fc3GM2EyhkjLPhhT4Uk5aiK6JZAAyJeL4/ACnX KI4lOrMefAt9DJ5OzeiGBko6URfo8s83DpVrk9XG4VYxl6tA6S6wRkm7+zV+sUVoFY5J b7nTbpdFCoEoDuXbKC0OOr5XdB+eeLXGdXI+/Ej9eUV+Dj0OhSDnOTuT2iGtUs9whC2L 5C8Gln1ebAU2yc76KN/NpRSgSxUwS608hcZxQeKEwnd7ZqPeesvNwK/KOoAPnpuBAY6g q41Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h72ifJ+7tHEcaNV/1J9doeqDVxjtwj2qyJWIRUQqoxI=; b=AjYnwSoeoK4BL8Qb3Tdl274jRHyw+1TBStzK/Fup+XwRgtYtNv6u4H0YyeMSfToGhN PLi1eZewT7XPY5tegNg8VIFG9WHIM6P1CAdOOqLxgxresxh72MBt1X6fsp0KKOUnIpYd Fop3+8chdOZZ1CvAKKxkEa0NdbRiI8uf7YU2l6j3gN9f26aFnwW5WyBqpYs/rahncPJb ZClxo7B8iFet+bFd+d8bFX6oL0yv6D9wC8AxBSD1UF5tDbPyb2GPJIJQZ5NY1t8OHqSS zM0mGloXBxLxPus3rUg4410uoF4whQxo799BSsQhr4bZS49ytIDZzJbSsxqAnyQ9TIrW KGKg== X-Gm-Message-State: AKS2vOxeND6Zd0SNHnfba/24gWaBKqXr8N4hC803fXM8gOUL04iMw+Mb HbsUAnHGFquQuWQkG9vBqPOtyqGJR1M2 X-Received: by 10.107.18.16 with SMTP id a16mr33298682ioj.93.1498071209719; Wed, 21 Jun 2017 11:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Wed, 21 Jun 2017 11:53:08 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> From: Marius Scurtescu Date: Wed, 21 Jun 2017 11:53:08 -0700 Message-ID: To: "M.Lizar@OCG" Cc: Mike Jones , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="001a113ee31e4e700905527ce2b7" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:53:37 -0000 --001a113ee31e4e700905527ce2b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG wrote: > FWIW - I agree with Mike that putting restrictions on the "sub" claim > usage would unnecessarily complicate SETs for some use cases. > sub is defined as optional in JWT, so technically we are not adding any restrictions. Do you have examples of use cases that cannot handle sub at the event level? > Its a lot easier to add to a spec and very difficult (if not impossible) > to retract. > I agree. I don't think anything is retracted. Again, see: https://tools.ietf.org/html/rfc7519#section-4.1.2 Last sentence of 4.1.2 states "Use of this claim is OPTIONAL." > In this regard, keeping it simple is critical for broad adoption. > > Mark > > On 19 Jun 2017, at 16:55, Marius Scurtescu wrote: > > Mike, are you suggesting we define SETs in such a way that they will not > work for RISC? A top level iss+sub is clearly not working for RISC, and m= ay > not work for logout either if you allow logout to be initiated from an RP= . > > Marius > > On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones > wrote: > >> Marius, there=E2=80=99s nothing stopping you (or the RISC working group = or other >> profiles) from defining events that can be sent from RPs to IdPs now, >> without any changes to the SET spec. Specify the claims you want to use= , >> and you=E2=80=99re golden. >> >> >> >> But it would be counterproductive to require all other SETs to meet the >> requirements of your specific profile. There are simpler use cases that >> can use claims in simpler ways. Trying to make the simple use cases be >> complex will have the side effect of limiting the adoption of the spec, >> which wouldn=E2=80=99t be good for anyone. >> >> >> >> If successful, SETs will have many different profiles. That=E2=80=99s a= sign of >> success =E2=80=93 not a sign of weakness. >> >> >> >> -- Mike >> >> >> >> *From:* Marius Scurtescu [mailto:mscurtescu@google.com] >> *Sent:* Monday, June 19, 2017 11:58 AM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer ; Justin Richer < >> jricher@mit.edu>; Richard Backman, Annabelle ; Henk >> Birkholz ; ID Events Mailing List < >> id-event@ietf.org>; Phil Hunt >> >> *Subject:* Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> >> On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones >> wrote: >> >> I=E2=80=99m sorry to be slow replying to some messages in this thread. = I have a >> lot of other things on my plate, but I will take the time now to reply, >> because I wholeheartedly disagree with some of the statements below and >> believe it would be severely harmful to the specification and its adopti= on >> to act upon them. Specifically: >> >> >> >> - I disagree that specific rules should be made for the =E2=80=9Csub= =E2=80=9D claim. >> Claims usage needs to be up to the application. I know that many oth= ers >> agree with me, because the OpenID Connect working group designed the = logout >> token in http://openid.net/specs/openid-connect-backchannel-1_0-04. >> html#LogoutToken (which is also used as an example in >> https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 >> ) >> to use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibitin= g this usage would be >> a completely unnecessary breaking change =E2=80=93 as it=E2=80=99s im= possible to confuse a >> logout token with an ID Token, for reasons already cites in this thre= ad. >> >> Solving the confusion is one problem. The other problem I keep mentionin= g >> is SETs issued by an RP to be sent to an IdP. How are we solving that >> problem Mike? In this case the top level iss is different from the iss o= f >> the sub, a top level sub is not possible. >> >> >> >> And I don't want to downplay the confusion problem either. I think it is >> a real concern and I think a solid solution is important. >> >> >> >> The OpenID Working Group designed logout tokens without secevent in mind= . >> I agree we should not recklessly break compatibility, but to me it seems >> necessary in this case. >> >> >> >> >> - >> >> >> >> - (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at >> https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 >> . >> No further =E2=80=9Ciss=E2=80=9D rules are needed.) >> >> >> >> Further iss ruies are absolutely needed for the RP to IdP case described >> above. >> >> >> >> >> >> >> - >> >> >> >> - It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to= be used for some >> profiles to differentiate between kinds of JWTs. Its use should not = be >> mandated in the SET spec. I would oppose duplicating the =E2=80=9Cty= p=E2=80=9D >> functionality by defining another claim with a duplicative meaning. >> >> If typ can be use and no other claim is needed, then let's talk about >> that. I do think SET should mandate it. I don't understand why not. Can = you >> please propose with examples how can typ be used? >> >> >> >> >> >> >> - >> >> >> >> - I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile >> of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D This reflect= s a >> misunderstanding. It=E2=80=99s the **value** of the nonce that self-= secures >> the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is prese= nt. Any and all JWTs can >> simultaneously use =E2=80=9Cnonce=E2=80=9D without any risk of confli= ct, since the nonce >> value is a cryptographically secure random number. >> >> >> >> For SETs I cannot see how the nonce value is useful. That value is not >> passed back and it cannot be verified. Only the presence of the claim co= uld >> have some use, hinting at the usage of the JWT, a very weak solution to = the >> confusion problem. >> >> >> >> >> - >> >> >> >> Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d= be glad >> to have in-person discussions about these topics there. >> >> >> >> -- Mike >> >> >> >> P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (o= r any other >> claim) or forcing it to be located in a non-standard location makes abou= t >> as much sense as arbitrarily saying that, for a particular profile, the >> Latin word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the c= laim name instead >> of =E2=80=9Csub=E2=80=9D. Yes, it will completely differentiate this pr= ofile from others >> not spelling the claim name this way, but it would certainly be an >> impediment to the use of standard JWT libraries and to interoperability. >> >> >> >> If we define that sub must be at the event level then it is at a standar= d >> location, I don't see what the issue is. The impediment you mention is t= he >> actual solution. I don't think that a JWT library that was written for I= d >> Tokens should be used to parse SETs. The library has to be SET aware, in >> which case the event level iss+sub is not an issue at all. >> >> >> >> >> >> >> >> >> >> *From:* Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> *Sent:* Saturday, June 17, 2017 1:45 PM >> *To:* Justin Richer ; Marius Scurtescu < >> mscurtescu@google.com> >> *Cc:* Richard Backman, Annabelle ; Mike Jones < >> Michael.Jones@microsoft.com>; Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List < >> id-event@ietf.org>; Phil Hunt >> >> >> *Subject:* Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> >> So to summarize what I'm seeing on this thread: >> >> Everybody agrees with Marius's short-term solution, specific rules for >> "sub" and "iss" that can be defined in the SET spec. >> >> Almost everybody agrees on a long-term "usage" claim ("type" is taken) >> that should be defined elsewhere, e.g. in the JWT BCP. >> >> Did I miss anything? >> >> By the way, if we do add a "usage" claim, we need to also use it in the >> SET document before it is published. >> >> Thanks, >> >> Yaron >> >> >> >> On 15/06/17 22:08, Justin Richer wrote: >> >> +1 to this as well. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu >> wrote: >> >> >> >> +1 to what Annabelle said. >> >> >> >> Also, Mike you are missing the other requirement, for RPs to send events >> to an IdP. The iss+sub pair at the top level is broken in this case. >> >> >> Marius >> >> >> >> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) >> wrote: >> >> +1 >> >> >> >> Phil >> >> >> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Mike, >> >> >> >> Your explanation for why this is a non-problem is dependent upon side >> effects of elements of OpenID Connect that were not designed to solve th= is >> issue. As a result, I see several issues with it: >> >> 1. The caller of the Token Endpoint is the only party that can be >> certain that a nonce-less ID Token is really an ID Token. Any party that >> the caller passes the ID Token off to has no way to verify its provenanc= e. >> >> 2. Any future ID Token distribution method needs to solve this >> problem again. >> >> 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. >> >> 4. This is only a solution for ID Tokens. Every other JWT profile >> that cares about disambiguation has to invent its own solution to the >> problem. >> >> >> >> We know from experience that naming collisions and replay attacks are >> both things that happen. What=E2=80=99s being proposed is a simple, defe= nsive >> measure against these risks. You brought up JWT libraries: a general >> solution actually makes it easier to use common libraries for JWT parsin= g. >> A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation = for any JWT >> profile, whereas with the status quo each profile would require unique >> logic. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> >> >> >> >> *From: *Id-event on behalf of Mike Jones < >> Michael.Jones@microsoft.com> >> *Date: *Wednesday, June 14, 2017 at 1:16 PM >> *To: *Marius Scurtescu >> *Cc: *"Richard Backman, Annabelle" , ID Events >> Mailing List , Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> >> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals >> in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 maki= ng things that can and >> should be simple complex, without data showing there=E2=80=99s any need = to do so. >> >> >> >> Mandatory solutions are being proposed in this thread to problems that >> there=E2=80=99s no evidence that we actually even have. It=E2=80=99s al= ready been >> established that it=E2=80=99s impossible for a SET to be confused for an= ID Token =E2=80=93 >> see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html >> . >> If people have data showing that this is possible with specific kinds of >> Access Tokens or other real JWT deployments, please provide specifics, s= o >> that we can use that data to inform appropriate engineering choices on o= ur >> part. >> >> >> >> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of= =E2=80=9Csub=E2=80=9D in the >> normal way, or requiring a type claim, would make previously simple thin= gs >> unnecessarily complex. Yes, then the result is then different than a >> normal JWT but a consequence of this is that custom parsing code would h= ave >> to be used, rather than a standard JWT parser. The more unwieldy we mak= e >> it to use SETs, the more likely developers are to just create their own >> data structures. Keeping it simple is the key to adoption. Standards a= re >> only useful if they are actually used. >> >> >> >> -- Mike >> >> >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org >> ] *On Behalf Of *Richard Backman, Annabelle >> *Sent:* Tuesday, June 13, 2017 5:33 PM >> *To:* Marius Scurtescu ; Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> >> *Cc:* ID Events Mailing List >> *Subject:* Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> >> Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? >> >> >> >> To your first question, I think a better analogy would be the X.509 Key >> Usage extension: a multi-valued property that declares the intended purp= ose >> of the JWT, and that a recipient may refer to when determining whether t= o >> accept a JWT being presented to it in some context. >> >> >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> >> >> >> >> *From: *Id-event on behalf of Marius >> Scurtescu >> *Date: *Tuesday, June 13, 2017 at 11:05 AM >> *To: *Henk Birkholz >> *Cc: *ID Events Mailing List >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> >> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> wrote: >> >> And a 2nd question. >> >> What semantics would "usage" provide that that are not covered via >> "intend", "audience", and "scope"? >> >> >> >> "aud" (audience) specifies the target client, but not the intended usage >> (access token to authorize resource access or SET to communicate a secur= ity >> event?) >> >> >> >> "scope" is not used by SET. >> >> >> >> I don't know what do you mean by "intend" (or intent)? >> >> >> >> >> >> >> >> Henk >> >> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >> >> Thanks for putting this together! >> >> I think the assumptions inherent in 3.9 are flawed: >> >> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutu= ally exclusive >> set of valid claims and/or header parameters, and enforcing this require= s a >> =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that = JWTs from some >> future spec can=E2=80=99t be mistaken for JWTs from a current spec. >> >> =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80= =9Cdifferent >> keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by the = spec or >> not, implementers will ignore this because managing one key is easier th= an >> managing N different keys. >> >> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >> >> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter. >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> *From: *Id-event on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Monday, June 12, 2017 at 3:18 PM >> *To: *Marius Scurtescu >> *Cc: *Adam Dawes , "matake, nov" , ID >> Events Mailing List , "Phil Hunt (IDM)" < >> phil.hunt@oracle.com> >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> Agreed. Note that there is still lots of discussion on what should be in >> 3.9. >> >> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > > wrote: >> >> Thanks for the pointer Dick, very good timing :-) >> >> The issue is described by "2.7. Cross-JWT Confusion" and the >> mitigation is in "3.9. Use Mutually Exclusive Validation Rules for >> Different Kinds of JWTs", specifically "Use different sets of >> required claims...", "Use different keys for different kinds of >> JWTs." and "Use different issuers for different kinds of JWTs.". >> >> I still think that a "type" claim would bring a lot of clarity and >> safety. >> >> >> Marius >> >> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > > wrote: >> >> Yaron, Mike and I just published an BCP ID for JWT >> http://self-issued.info/?p=3D1690 >> >> >> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > > wrote: >> >> I was initially a fan of keeping SETS to be very similar to >> id tokens but I now think this is a better plan. >> >> On Thu, Jun 8, 2017 at 6:56 PM matake, nov > > wrote: >> >> +1 especially for "type" >> >> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >> >: >> >> +1 >> >> Phil >> >> >> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> > >> > wrote: >> > >> > There were a couple of proposals on how to >> distinguish SETs from Id Tokens and Access Tokens in >> such a way that naive implementations will not >> confuse one for the other and open up security >> vulnerabilities. >> > >> > There is also another important requirement: the >> SET issuer in some cases must be different from the >> "sub" issuer. This is the case of an RP sending SETs >> to an IdP. >> > >> > With these requirements in mind I propose the >> following: >> > - both "sub" and "iss" to be defined at the event >> level >> > - "iss" at event level and at top SET level can >> be different >> > - "iss" and "sub" at event level can be different >> across events in the same SET >> > - "sub" should NOT be present at the top SET >> level (this solves the disambiguation), please note >> "should" and not "must" >> > >> > This solution also allows different profiles that >> define event types to define additional claims >> related to sub (like email or phone_number) and >> since all these claims will be at the event level >> there will be no collisions or ambiguity. >> > >> > Another proposal (which I supported) was to >> define a composite "aud" claim. This is not solving >> the requirement for a distinct SET issuer. Also, >> having the same claim name having different syntax >> in different token types could lead to confusion. >> > >> > And yet another proposal was to introduce a new >> claim for JWTs that defines a "type". This is not >> practical in the short term, and it also is not >> solving the distinct issuer requirement, but I think >> this is something the JWT group should seriously >> consider. >> > >> > Thoughts? >> > >> > Marius >> >> > _______________________________________________ >> > Id-event mailing list >> >> > Id-event@ietf.org >> > >> https://urldefense.proofpoint. >> com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Dev >> ent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10& >> r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp >> 74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88 >> YKOCd0mxPQFJLhxWI&e=3D >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> -- >> Adam Dawes | Sr. Product Manager |adawes@google.com >> |+1 650-214-2410 >> > >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> -- >> Subscribe to the HARDTWARE > > >> mail list to >> learn about projects I am working on! >> >> >> >> -- >> >> Subscribe to the HARDTWARE > > >> mail list to learn about projects I am working on! >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz >> jWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_ >> 3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> >> _______________________________________________ >> >> Id-event mailing list >> >> Id-event@ietf.org >> >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > --001a113ee31e4e700905527ce2b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG <m.lizar@openconsentgroup.com> wrote:
FWIW - I agree with Mike that putting restrictions on the "sub= " claim usage would unnecessarily complicate SETs for some use cases.<= /span>

sub is defined as optional in = JWT, so technically we are not adding any restrictions. Do you have example= s of use cases that cannot handle sub at the event level?



Its a lot = easier to add to a spec and very=C2=A0difficult=C2=A0(if not impossible) to retract.=

I agree. I don= 9;t think anything is retracted.

Again, see:
=

= Last sentence of 4.1.2 states "Use of this claim is OPTIONAL."

=C2=A0
In this regard, keeping it simple is critical for broad adoption.= =C2=A0

Mark
<= font color=3D"rgba(0, 0, 0, 0.85098)">
On 19 Jun 2017, at 16:55, Marius Scurtescu <mscurtescu@google.com> wrote:

Mike, are you= suggesting we define SETs in such a way that they will not work for RISC? = A top level iss+sub is clearly not working for RISC, and may not work for l= ogout either if you allow logout to be initiated from an RP.

Marius

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones = <Michael.Jones@micros= oft.com> wrote:

Marius, there=E2= =80=99s nothing stopping you (or the RISC working group or other profiles) = from defining events that can be sent from RPs to IdPs now, without any cha= nges to the SET spec.=C2=A0 Specify the claims you want to use, and you=E2=80=99re golden.

=C2=A0

<= p class=3D"MsoNormal">But it would be co= unterproductive to require all other SETs to meet the requirements of your = specific profile.=C2=A0 There are simpler use cases that can use claims in = simpler ways.=C2=A0 Trying to make the simple use cases be complex will have the side effect of limiting the adoption of the= spec, which wouldn=E2=80=99t be good for anyone.

<= p class=3D"MsoNormal">=C2=A0

If s= uccessful, SETs will have many different profiles.=C2=A0 That=E2=80=99s a s= ign of success =E2=80=93 not a sign of weakness.

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mailto:<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"gmail-cr= emed gmail-cremed cremed">mscurtescu@google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@mi= crosoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.c= om>; Justin Richer <jricher@mit.edu>;= Richard Backman, Annabelle <richanna@amazon.co= m>; Henk Birkholz <henk.birk= holz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <= ;Michael.Jones@microsoft.com> wrote= :

I=E2=80=99m = sorry to be slow replying to some messages in this thread.=C2=A0 I have a l= ot of other things on my plate, but I will take the time now to reply, beca= use I wholeheartedly disagree with some of the statements below and believe it= would be severely harmful to the specification and its adoption to act upo= n them.=C2=A0 Specifically:

= =C2=A0

Solving the confusion is one problem. The other= problem I keep mentioning is SETs issued by an RP to be sent to an IdP. Ho= w are we solving that problem Mike? In this case the top level iss is diffe= rent from the iss of the sub, a top level sub is not possible.

=C2=A0

And I don't want to downplay the confusion = problem either. I think it is a real concern and I think a solid solution i= s important.

=C2=A0

The OpenID Working Group designed logout tokens= without secevent in mind. I agree we should not recklessly break compatibi= lity, but to me it seems necessary in this case.

=C2=A0

  • =C2=A0

=C2=A0

=C2=A0

Further iss ruies are absolutely needed for the= RP to IdP case described above.

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used= for some profiles to differentiate between kinds of JWTs.=C2=A0 Its use sh= ould not be mandated in the SET spec.=C2=A0 I would oppose duplicating the = =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a duplic= ative meaning.

If typ can be use and no other claim is needed,= then let's talk about that. I do think SET should mandate it. I don= 9;t understand why not. Can you please propose with examples how can typ be= used?

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D=C2=A0 This reflects a misunderstanding.=C2=A0 It=E2=80=99s th= e *value* of the nonce that self-secures the JWT =E2=80=93 not that = any =E2=80=9Cnonce=E2=80=9D claim is present.=C2=A0 Any and all JWTs can simultaneously use =E2=80=9Cn= once=E2=80=9D without any risk of conflict, since the nonce value is a cryp= tographically secure random number.

=C2=A0

For SETs I cannot see how the nonce value is us= eful. That value is not passed back and it cannot be verified. Only the pre= sence of the claim could have some use, hinting at the usage of the JWT, a = very weak solution to the confusion problem.

=C2=A0

  • =C2=A0

=C2=A0

Will some of you be at the Cloud Identity Summit= next week?=C2=A0 I=E2=80=99d be glad to have in-person discussions about t= hese topics there.

=C2=A0

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

=C2=A0

P.S.=C2=A0 Food for thought:=C2=A0 Prohibiting t= he use of =E2=80=9Csub=E2=80=9D (or any other claim) or forcing it to be lo= cated in a non-standard location makes about as much sense as arbitrarily saying that, for a particular profile, the Latin word= for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name ins= tead of =E2=80=9Csub=E2=80=9D.=C2=A0 Yes, it will completely differentiate = this profile from others not spelling the claim name this way, but it would certainly be an impediment to the use of standard JWT libraries and = to interoperability.

=C2=A0

If we define that sub must be at the event leve= l then it is at a standard location, I don't see what the issue is. The= impediment you mention is the actual solution. I don't think that a JW= T library that was written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case the = event level iss+sub is not an issue at all.

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= u>

= From: Yaron Sheffer [mailto:yaronf.ietf@g= mail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; = Marius Scurtescu <mscurtescu@google.com&g= t;
Cc: Richard Backman, Annabelle <richanna= @amazon.com>; Mike Jones <Michae= l.Jones@microsoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>= ;; Phil Hunt <phil.hunt@oracle.com><= /u>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So to summarize what= I'm seeing on this thread:

Everybody agrees with M= arius's short-term solution, specific rules for "sub" and &qu= ot;iss" that can be defined in the SET spec.

Almos= t everybody agrees on a long-term "usage" claim ("type"= is taken) that should be defined elsewhere, e.g. in the JWT BCP.=

Did I miss anything?

By the way, if we do ad= d a "usage" claim, we need to also use it in the SET document bef= ore it is published.

Thanks,

=C2=A0= =C2=A0=C2=A0 Yaron

=C2=A0=

On 15/06/17 22:08, Justin Richer wrote:<= u>

+1 to this as well.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu &= lt;mscurtescu@google.com> wrote:

=C2=A0

+1 to what Annabelle said.

=C2=A0

Also, Mike you are missing the other requiremen= t, for RPs to send events to an IdP. The iss+sub pair at the top level is b= roken in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM= ) <phil.hunt@oracle.com> wrote:<= u>

+1

=C2=A0=

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Mike,

= =C2=A0

Your explanation for why thi= s is a non-problem is dependent upon side effects of elements of OpenID Con= nect that were not designed to solve this issue. As a result, I see several issues with it:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certa= in that a nonce-less ID Token is really an ID Token. Any party that the cal= ler passes the ID Token off to has no way to verify its provenance.<= u>

2.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem = again.

3.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim.=

4.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that = cares about disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and replay attack= s are both things that happen. What=E2=80=99s being proposed is a simple, d= efensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use commo= n libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library co= uld handle disambiguation for any JWT profile, whereas with the status quo = each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identit= y Services

=C2=A0

=C2=A0

= From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael= .Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@googl= e.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

You=E2=80= =99ve heard of =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d = characterize the proposals in this thread as =E2=80=9Cpremature pessimation= =E2=80=9D =E2=80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0

Mandatory solutions are being proposed in this thre= ad to problems that there=E2=80=99s no evidence that we actually even have.= =C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.h= tml.=C2=A0 If people have data showing that this is possible with speci= fic kinds of Access Tokens or other real JWT deployments, please provide sp= ecifics, so that we can use that data to inform appropriate engineering choices on our part.

=C2=A0

The prop= osed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9Cs= ub=E2=80=9D in the normal way, or requiring a type claim, would make previo= usly simple things unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0

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

=C2=A0

= From: Id-event [mailto:id-event-boun= ces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@googl= e.com>; Henk Birkholz <henk.= birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.= org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80= =9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better an= alogy would be the X.509 Key Usage extension: a multi-valued property that = declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to i= t in some context.

=C2=A0=

--=C2=A0

Annabelle Richard Backman

Identit= y Services

=C2=A0

=C2=A0

= From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurte= scu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birk= holz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.= org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = <henk.birkholz@sit.fraunhofer.= de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target= client, but not the intended usage (access token to authorize resource acc= ess or SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.=

=C2=A0

I don't know what do you mean by "inte= nd" (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.o= rg> on behalf of Dick Hardt <dick.hardt= @gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.co= m>
*Cc: *Adam Dawes <adawes@google.com>, &quo= t;matake, nov" <nov@matake.jp>, ID Events= Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle= .com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscur= tescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com= >> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" class=3D"gmail-cremed= gmail-cremed cremed">adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google= .com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov= @matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com <mailto:ph= il.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"gmail-cr= emed gmail-cremed cremed">mscurtescu@google.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mscurtescu@g= oogle.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv<= wbr>lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz<= wbr>jWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqm= g&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:I= d-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.o= rg>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(6= 50)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@i= etf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.= com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-eve= nt


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-eve= nt

=C2=A0

=C2=A0

_________________________________________= ______
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/l= istinfo/id-event

=C2=A0



_______________________________________________

Id-event mailing list


Id-event@ietf.org


https://www.ietf.org/mail=
man/listinfo/id-event

=C2=A0

=C2=A0


_______________________________________________
Id-event mailing li= st
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=

<= /div>
--001a113ee31e4e700905527ce2b7-- From nobody Wed Jun 21 13:19:42 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32544129498 for ; Wed, 21 Jun 2017 13:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbQwC4Acy8ml for ; Wed, 21 Jun 2017 13:19:36 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0102.outbound.protection.outlook.com [104.47.41.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B588129493 for ; Wed, 21 Jun 2017 13:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8zu6VtuFbT5EifJE474xzlv/i+4Cy5DJckc8ClLVjg4=; b=GmAXT0CE0Pcw2xGRe/qNIX8++JFNtFX8QBVwArBcCcUc+Ls7jSgKGeTdoPjKNUVBbsNSJHasoJyb1qS62do0GxG6lkbiktC6085ytQG1qVH02jA+QtmDNSRoSf3f6rrwWQED9+fzDQHoLT+hW6B+BOmEkQH9EJQdscpTAAMfBek= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0469.namprd21.prod.outlook.com (10.172.121.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Wed, 21 Jun 2017 20:19:33 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.000; Wed, 21 Jun 2017 20:19:33 +0000 From: Mike Jones To: Marius Scurtescu , "M.Lizar@OCG" CC: "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , "Yaron Sheffer" , ID Events Mailing List , Phil Hunt Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAAAQ5CAAwZmgIAAKJzwgAAI8wCAAvAHAIAAAcwAgAAQ2kA= Date: Wed, 21 Jun 2017 20:19:33 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-21T15:19:29.5437880-05:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [208.59.64.25] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0469; 7:sS7awCkH3ch8hB0YfWkukQA9A5Ujyqpfls/ymAtdreP++urSm990aGF4U4lRxyYkoXXiwW3qy3ZXD4yFGFa8uHLjiqnmT3BHoUYauQeQk1AOe6OJevMdMvazX9a/CtVwuf8SGxaNA4tXvDBQEgVPGS/O2QlCwHG8+tqifxAN33GeAVjNHmXayLRIyb8SsMuc1jwt/ZXVjh8Ai+NxOLb8rLh5ICNIzzUt0lv0Nt8DzqXolJKndue7wYVFV0x6RLpQ4f7uW0004fSQMHuhGk1MSLB+5fSL27/aS5JonLlnhjUPuvfLzr/2f0rDGcUvoSTh1v3UXolysMeL9eGDohfoeK5eaMRJd+JQN6SMvj5sP4gN+Fr8QG4ucUkr8Mt/8PrOyhH8mtBXmVFD8rGtjKzV8ykmcyqVR7M9tiQt8iSS/itqTiDxizcLhA3YX9DR5vpURw0K3EAusDZTn6rG8LF59duUhGxEAS2YQmIYvEo45SGD5XMR0fnoqJ6UdRSYNMeuQw/nI26Xo2jxJCsgRmwUgSOpyNS5aTDGPRVINxWdgPgGO0U6YMN3TjFl/q/7KqCP9kOAJl79IXxHCEdxsQ+b9g/A0Ho1N6glL8iAaC1OYScNeaMLAnJoDKLS5ec0sInd6ZBc5i7TssMGQjLSUhOpNZMnPBWFg+58gvO9stWGbGzhbdTA7cJnst9FR66XGSeqZKkT5Y35arhtXwoHGykeawSqY+5jEfB6iRSk5iTo87Ilhz8jAb6QDDimYRnDtFaLMcGiD6clm98XsuR3/kqv9qc1ai5RgGq3NBiZRJ8ue4kAl1TN9DF6HtafV1t5aj2l x-ms-office365-filtering-correlation-id: f94d3fbb-0a50-4749-fbc9-08d4b8e2d480 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:CY4PR21MB0469; x-ms-traffictypediagnostic: CY4PR21MB0469: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(47284530071512)(10436049006162)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0469; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0469; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39400400002)(39450400003)(39410400002)(39840400002)(39850400002)(209900001)(377424004)(24454002)(377454003)(51914003)(8936002)(50986999)(76176999)(5660300001)(54356999)(81166006)(7696004)(122556002)(189998001)(7906003)(561944003)(33656002)(7736002)(74316002)(93886004)(54896002)(25786009)(236005)(53376002)(6246003)(99286003)(53946003)(54906002)(6306002)(55016002)(4326008)(9686003)(16200700003)(2950100002)(10290500003)(53936002)(966005)(14454004)(77096006)(53546010)(39060400002)(8676002)(229853002)(72206003)(38730400002)(2900100001)(5005710100001)(3660700001)(102836003)(10090500001)(86612001)(3846002)(3280700002)(6506006)(6436002)(19609705001)(606005)(790700001)(6116002)(8990500004)(575784001)(86362001)(478600001)(2906002)(66066001)(491001)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0469; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504679FEF878DC7BEDECA9BF5DA0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 20:19:33.0472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0469 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:19:41 -0000 --_000_CY4PR21MB0504679FEF878DC7BEDECA9BF5DA0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaXVzLCB0aGUgcXVlc3Rpb24g4oCcRG8geW91IGhhdmUgZXhhbXBsZXMgb2YgdXNlIGNhc2Vz IHRoYXQgY2Fubm90IGhhbmRsZSBzdWIgYXQgdGhlIGV2ZW50IGxldmVsP+KAnSBpcyBubyBtb3Jl IHVzZWZ1bCB0aGFuIHRoZSBxdWVzdGlvbiDigJxEbyB5b3UgaGF2ZSBleGFtcGxlcyBvZiB1c2Ug Y2FzZXMgdGhhdCBjYW5ub3QgaGFuZGxlIOKAmHN1YuKAmSBzcGVsbGVkIGFzIHRoZSBMYXRpbiB3 b3JkIOKAmHN1YmllY3R1beKAmT/igJ0gIFllcywgYXBwbGljYXRpb25zIGNvdWxkIGFsd2F5cyB3 b3JrIGFyb3VuZCB0aGUgaW5jb252ZW5pZW5jZXMgaW50cm9kdWNlZCBieSBhcmJpdHJhcnkgY2xh aW0gcmVuYW1pbmcgb3IgcmVwb3NpdGlvbmluZywgYnV0IHRoZXkgc2hvdWxkbuKAmXQgaGF2ZSB0 by4gIEl0IGp1c3QgYWRkcyBjb21wbGV4aXR5IGFuZCB3aWxsIGhpbmRlciBhZG9wdGlvbi4NCg0K SXQgc2VlbXMgdG8gbWUgdGhhdCB5b3VyIG1vdGl2YXRpb24gZm9yIGFsd2F5cyBoYXZpbmcg4oCc c3Vi4oCdIGluIHRoZSBldmVudCBwYXlsb2FkLCByYXRoZXIgdGhhbiBhIG5vcm1hbCBjbGFpbSwg aXMgdGhhdCB0aGF04oCZcyBob3cgeW91IHRoaW5rIFJJU0MgZXZlbnRzIHdpbGwgYmUgc3RydWN0 dXJlZCwgYW5kIHRoYXQgeW91IHdhbnQgKmFsbCogZXZlbnRzIHRvIGFsc28gdXNlIHRoZSBSSVND IGV2ZW50IHN0cnVjdHVyaW5nLiAgVG8gbXkgd2F5IG9mIHRoaW5raW5nLCBpZiB5b3UgcmVhbGx5 IGJlbGlldmUgdGhhdCB5b3Ugc2hvdWxkIGJlIGFza2luZyB0aGUgU0VUIHNwZWMgdG8gYmUgd2l0 aGRyYXduIGZyb20gdGhlIElFVEYgYW5kIG9ubHkgZGVmaW5lIFJJU0MgZXZlbnRzIGluIHRoZSBS SVNDIHdvcmtpbmcgZ3JvdXAuICBCdXQgaW4gZmFjdCwgcmVxdWlyaW5nIGFsbCBldmVudHMgdG8g Zm9sbG93IHRoZSBSSVNDIGNvbnZlbnRpb25zIG1ha2VzIG5vIG1vcmUgc2Vuc2UgdGhhbiByZXF1 aXJpbmcgYWxsIEpXVHMgdG8gYmUgSUQgVG9rZW5zLiAgVGhhdCB3b3VsZCBoYXZlIG1hZGUgSldU cyB1c2VsZXNzIGZvciBtYW55IHVzZSBjYXNlcy4gIFByb3Bvc2luZyB0byBsaW1pdCBjbGFpbXMg dXNhZ2UgaW4gU0VUcyB3b3VsZCBsaWtld2lzZSBtYWtlIHRoZW0gaW5hcHBsaWNhYmxlIGZvciBt YW55IG5vbi1SSVNDIHVzZSBjYXNlcy4NCg0KV2UgaGF2ZSBhIHBvdGVudGlhbCBzdWNjZXNzIG9u IG91ciBoYW5kcy4gIExldOKAmXMgbm90IHNjcmV3IGl0IHVwIGJ5IG1ha2luZyBpdCB1bm5lY2Vz c2FyaWx5IGNvbXBsaWNhdGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IFtt YWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDIxLCAy MDE3IDE6NTMgUE0NClRvOiBNLkxpemFyQE9DRyA8bS5saXphckBvcGVuY29uc2VudGdyb3VwLmNv bT4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbT47IEhlbmsgQmlya2hvbHog PGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+OyBKdXN0aW4gUmljaGVyIDxqcmljaGVy QG1pdC5lZHU+OyBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+OyBJRCBFdmVu dHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz47IFBoaWwgSHVudCA8cGhpbC5odW50 QG9yYWNsZS5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNj ZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpPbiBXZWQsIEp1 biAyMSwgMjAxNyBhdCAxMTo0NiBBTSwgTS5MaXphckBPQ0c8bWFpbHRvOk0uTGl6YXJAT0NHPiA8 bS5saXphckBvcGVuY29uc2VudGdyb3VwLmNvbTxtYWlsdG86bS5saXphckBvcGVuY29uc2VudGdy b3VwLmNvbT4+IHdyb3RlOg0KRldJVyAtIEkgYWdyZWUgd2l0aCBNaWtlIHRoYXQgcHV0dGluZyBy ZXN0cmljdGlvbnMgb24gdGhlICJzdWIiIGNsYWltIHVzYWdlIHdvdWxkIHVubmVjZXNzYXJpbHkg Y29tcGxpY2F0ZSBTRVRzIGZvciBzb21lIHVzZSBjYXNlcy4NCg0Kc3ViIGlzIGRlZmluZWQgYXMg b3B0aW9uYWwgaW4gSldULCBzbyB0ZWNobmljYWxseSB3ZSBhcmUgbm90IGFkZGluZyBhbnkgcmVz dHJpY3Rpb25zLiBEbyB5b3UgaGF2ZSBleGFtcGxlcyBvZiB1c2UgY2FzZXMgdGhhdCBjYW5ub3Qg aGFuZGxlIHN1YiBhdCB0aGUgZXZlbnQgbGV2ZWw/DQoNCg0KDQpJdHMgYSBsb3QgZWFzaWVyIHRv IGFkZCB0byBhIHNwZWMgYW5kIHZlcnkgZGlmZmljdWx0IChpZiBub3QgaW1wb3NzaWJsZSkgdG8g cmV0cmFjdC4NCg0KSSBhZ3JlZS4gSSBkb24ndCB0aGluayBhbnl0aGluZyBpcyByZXRyYWN0ZWQu DQoNCkFnYWluLCBzZWU6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0 aW9uLTQuMS4yDQoNCkxhc3Qgc2VudGVuY2Ugb2YgNC4xLjIgc3RhdGVzICJVc2Ugb2YgdGhpcyBj bGFpbSBpcyBPUFRJT05BTC4iDQoNCg0KSW4gdGhpcyByZWdhcmQsIGtlZXBpbmcgaXQgc2ltcGxl IGlzIGNyaXRpY2FsIGZvciBicm9hZCBhZG9wdGlvbi4NCg0KTWFyaw0KDQpPbiAxOSBKdW4gMjAx NywgYXQgMTY6NTUsIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCk1pa2UsIGFyZSB5b3Ugc3VnZ2Vz dGluZyB3ZSBkZWZpbmUgU0VUcyBpbiBzdWNoIGEgd2F5IHRoYXQgdGhleSB3aWxsIG5vdCB3b3Jr IGZvciBSSVNDPyBBIHRvcCBsZXZlbCBpc3Mrc3ViIGlzIGNsZWFybHkgbm90IHdvcmtpbmcgZm9y IFJJU0MsIGFuZCBtYXkgbm90IHdvcmsgZm9yIGxvZ291dCBlaXRoZXIgaWYgeW91IGFsbG93IGxv Z291dCB0byBiZSBpbml0aWF0ZWQgZnJvbSBhbiBSUC4NCg0KTWFyaXVzDQoNCk9uIE1vbiwgSnVu IDE5LCAyMDE3IGF0IDI6MjcgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpNYXJpdXMs IHRoZXJl4oCZcyBub3RoaW5nIHN0b3BwaW5nIHlvdSAob3IgdGhlIFJJU0Mgd29ya2luZyBncm91 cCBvciBvdGhlciBwcm9maWxlcykgZnJvbSBkZWZpbmluZyBldmVudHMgdGhhdCBjYW4gYmUgc2Vu dCBmcm9tIFJQcyB0byBJZFBzIG5vdywgd2l0aG91dCBhbnkgY2hhbmdlcyB0byB0aGUgU0VUIHNw ZWMuICBTcGVjaWZ5IHRoZSBjbGFpbXMgeW91IHdhbnQgdG8gdXNlLCBhbmQgeW914oCZcmUgZ29s ZGVuLg0KDQpCdXQgaXQgd291bGQgYmUgY291bnRlcnByb2R1Y3RpdmUgdG8gcmVxdWlyZSBhbGwg b3RoZXIgU0VUcyB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgeW91ciBzcGVjaWZpYyBwcm9m aWxlLiAgVGhlcmUgYXJlIHNpbXBsZXIgdXNlIGNhc2VzIHRoYXQgY2FuIHVzZSBjbGFpbXMgaW4g c2ltcGxlciB3YXlzLiAgVHJ5aW5nIHRvIG1ha2UgdGhlIHNpbXBsZSB1c2UgY2FzZXMgYmUgY29t cGxleCB3aWxsIGhhdmUgdGhlIHNpZGUgZWZmZWN0IG9mIGxpbWl0aW5nIHRoZSBhZG9wdGlvbiBv ZiB0aGUgc3BlYywgd2hpY2ggd291bGRu4oCZdCBiZSBnb29kIGZvciBhbnlvbmUuDQoNCklmIHN1 Y2Nlc3NmdWwsIFNFVHMgd2lsbCBoYXZlIG1hbnkgZGlmZmVyZW50IHByb2ZpbGVzLiAgVGhhdOKA mXMgYSBzaWduIG9mIHN1Y2Nlc3Mg4oCTIG5vdCBhIHNpZ24gb2Ygd2Vha25lc3MuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208 bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT5dDQpTZW50OiBNb25kYXksIEp1bmUgMTksIDIw MTcgMTE6NTggQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpDYzogWWFyb24gU2hlZmZlciA8 eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjsgSnVz dGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjsgUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hh bm5hQGFtYXpvbi5jb20+PjsgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+OyBJRCBFdmVu dHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5v cmc+PjsgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+Pg0KDQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNj ZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQoNCk9uIFNhdCwg SnVuIDE3LCAyMDE3IGF0IDI6MDYgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJ4oCZ bSBzb3JyeSB0byBiZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUgbWVzc2FnZXMgaW4gdGhpcyB0aHJl YWQuICBJIGhhdmUgYSBsb3Qgb2Ygb3RoZXIgdGhpbmdzIG9uIG15IHBsYXRlLCBidXQgSSB3aWxs IHRha2UgdGhlIHRpbWUgbm93IHRvIHJlcGx5LCBiZWNhdXNlIEkgd2hvbGVoZWFydGVkbHkgZGlz YWdyZWUgd2l0aCBzb21lIG9mIHRoZSBzdGF0ZW1lbnRzIGJlbG93IGFuZCBiZWxpZXZlIGl0IHdv dWxkIGJlIHNldmVyZWx5IGhhcm1mdWwgdG8gdGhlIHNwZWNpZmljYXRpb24gYW5kIGl0cyBhZG9w dGlvbiB0byBhY3QgdXBvbiB0aGVtLiAgU3BlY2lmaWNhbGx5Og0KDQoNCiAgKiAgIEkgZGlzYWdy ZWUgdGhhdCBzcGVjaWZpYyBydWxlcyBzaG91bGQgYmUgbWFkZSBmb3IgdGhlIOKAnHN1YuKAnSBj bGFpbS4gIENsYWltcyB1c2FnZSBuZWVkcyB0byBiZSB1cCB0byB0aGUgYXBwbGljYXRpb24uICBJ IGtub3cgdGhhdCBtYW55IG90aGVycyBhZ3JlZSB3aXRoIG1lLCBiZWNhdXNlIHRoZSBPcGVuSUQg Q29ubmVjdCB3b3JraW5nIGdyb3VwIGRlc2lnbmVkIHRoZSBsb2dvdXQgdG9rZW4gaW4gaHR0cDov L29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtYmFja2NoYW5uZWwtMV8wLTA0Lmh0bWwj TG9nb3V0VG9rZW4gKHdoaWNoIGlzIGFsc28gdXNlZCBhcyBhbiBleGFtcGxlIGluIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24t MikgdG8gdXNlIHRoZSDigJxzdWLigJ0gY2xhaW0gaW4gdGhlIG5vcm1hbCB3YXkuICBQcm9oaWJp dGluZyB0aGlzIHVzYWdlIHdvdWxkIGJlIGEgY29tcGxldGVseSB1bm5lY2Vzc2FyeSBicmVha2lu ZyBjaGFuZ2Ug4oCTIGFzIGl04oCZcyBpbXBvc3NpYmxlIHRvIGNvbmZ1c2UgYSBsb2dvdXQgdG9r ZW4gd2l0aCBhbiBJRCBUb2tlbiwgZm9yIHJlYXNvbnMgYWxyZWFkeSBjaXRlcyBpbiB0aGlzIHRo cmVhZC4NClNvbHZpbmcgdGhlIGNvbmZ1c2lvbiBpcyBvbmUgcHJvYmxlbS4gVGhlIG90aGVyIHBy b2JsZW0gSSBrZWVwIG1lbnRpb25pbmcgaXMgU0VUcyBpc3N1ZWQgYnkgYW4gUlAgdG8gYmUgc2Vu dCB0byBhbiBJZFAuIEhvdyBhcmUgd2Ugc29sdmluZyB0aGF0IHByb2JsZW0gTWlrZT8gSW4gdGhp cyBjYXNlIHRoZSB0b3AgbGV2ZWwgaXNzIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBpc3Mgb2YgdGhl IHN1YiwgYSB0b3AgbGV2ZWwgc3ViIGlzIG5vdCBwb3NzaWJsZS4NCg0KQW5kIEkgZG9uJ3Qgd2Fu dCB0byBkb3ducGxheSB0aGUgY29uZnVzaW9uIHByb2JsZW0gZWl0aGVyLiBJIHRoaW5rIGl0IGlz IGEgcmVhbCBjb25jZXJuIGFuZCBJIHRoaW5rIGEgc29saWQgc29sdXRpb24gaXMgaW1wb3J0YW50 Lg0KDQpUaGUgT3BlbklEIFdvcmtpbmcgR3JvdXAgZGVzaWduZWQgbG9nb3V0IHRva2VucyB3aXRo b3V0IHNlY2V2ZW50IGluIG1pbmQuIEkgYWdyZWUgd2Ugc2hvdWxkIG5vdCByZWNrbGVzc2x5IGJy ZWFrIGNvbXBhdGliaWxpdHksIGJ1dCB0byBtZSBpdCBzZWVtcyBuZWNlc3NhcnkgaW4gdGhpcyBj YXNlLg0KDQoNCiAgKg0KDQoNCiAgKiAgIChJIGFncmVlIHdpdGggdGhlIOKAnGlzc+KAnSBydWxl cyBhbHJlYWR5IGluIHBsYWNlIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMi4xLiAgTm8gZnVydGhlciDigJxpc3PigJ0g cnVsZXMgYXJlIG5lZWRlZC4pDQoNCkZ1cnRoZXIgaXNzIHJ1aWVzIGFyZSBhYnNvbHV0ZWx5IG5l ZWRlZCBmb3IgdGhlIFJQIHRvIElkUCBjYXNlIGRlc2NyaWJlZCBhYm92ZS4NCg0KDQoNCiAgKg0K DQoNCiAgKiAgIEl04oCZcyBmaW5lIGZvciB0aGUg4oCcdHlw4oCdIGhlYWRlciBwYXJhbWV0ZXIg dG8gYmUgdXNlZCBmb3Igc29tZSBwcm9maWxlcyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4ga2lu ZHMgb2YgSldUcy4gIEl0cyB1c2Ugc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBpbiB0aGUgU0VUIHNw ZWMuICBJIHdvdWxkIG9wcG9zZSBkdXBsaWNhdGluZyB0aGUg4oCcdHlw4oCdIGZ1bmN0aW9uYWxp dHkgYnkgZGVmaW5pbmcgYW5vdGhlciBjbGFpbSB3aXRoIGEgZHVwbGljYXRpdmUgbWVhbmluZy4N CklmIHR5cCBjYW4gYmUgdXNlIGFuZCBubyBvdGhlciBjbGFpbSBpcyBuZWVkZWQsIHRoZW4gbGV0 J3MgdGFsayBhYm91dCB0aGF0LiBJIGRvIHRoaW5rIFNFVCBzaG91bGQgbWFuZGF0ZSBpdC4gSSBk b24ndCB1bmRlcnN0YW5kIHdoeSBub3QuIENhbiB5b3UgcGxlYXNlIHByb3Bvc2Ugd2l0aCBleGFt cGxlcyBob3cgY2FuIHR5cCBiZSB1c2VkPw0KDQoNCg0KICAqDQoNCg0KICAqICAgSeKAmWxsIGFs c28gcmVzcG9uZCB0byBBbm5hYmVsbGXigJlzIGFzc2VydGlvbiB0aGF0IOKAnE5vIG90aGVyIHBy b2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgIm5vbmNl4oCdIGNsYWltLuKAnSAgVGhpcyBy ZWZsZWN0cyBhIG1pc3VuZGVyc3RhbmRpbmcuICBJdOKAmXMgdGhlICp2YWx1ZSogb2YgdGhlIG5v bmNlIHRoYXQgc2VsZi1zZWN1cmVzIHRoZSBKV1Qg4oCTIG5vdCB0aGF0IGFueSDigJxub25jZeKA nSBjbGFpbSBpcyBwcmVzZW50LiAgQW55IGFuZCBhbGwgSldUcyBjYW4gc2ltdWx0YW5lb3VzbHkg dXNlIOKAnG5vbmNl4oCdIHdpdGhvdXQgYW55IHJpc2sgb2YgY29uZmxpY3QsIHNpbmNlIHRoZSBu b25jZSB2YWx1ZSBpcyBhIGNyeXB0b2dyYXBoaWNhbGx5IHNlY3VyZSByYW5kb20gbnVtYmVyLg0K DQpGb3IgU0VUcyBJIGNhbm5vdCBzZWUgaG93IHRoZSBub25jZSB2YWx1ZSBpcyB1c2VmdWwuIFRo YXQgdmFsdWUgaXMgbm90IHBhc3NlZCBiYWNrIGFuZCBpdCBjYW5ub3QgYmUgdmVyaWZpZWQuIE9u bHkgdGhlIHByZXNlbmNlIG9mIHRoZSBjbGFpbSBjb3VsZCBoYXZlIHNvbWUgdXNlLCBoaW50aW5n IGF0IHRoZSB1c2FnZSBvZiB0aGUgSldULCBhIHZlcnkgd2VhayBzb2x1dGlvbiB0byB0aGUgY29u ZnVzaW9uIHByb2JsZW0uDQoNCg0KICAqDQoNCldpbGwgc29tZSBvZiB5b3UgYmUgYXQgdGhlIENs b3VkIElkZW50aXR5IFN1bW1pdCBuZXh0IHdlZWs/ICBJ4oCZZCBiZSBnbGFkIHRvIGhhdmUgaW4t cGVyc29uIGRpc2N1c3Npb25zIGFib3V0IHRoZXNlIHRvcGljcyB0aGVyZS4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K UC5TLiAgRm9vZCBmb3IgdGhvdWdodDogIFByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCd IChvciBhbnkgb3RoZXIgY2xhaW0pIG9yIGZvcmNpbmcgaXQgdG8gYmUgbG9jYXRlZCBpbiBhIG5v bi1zdGFuZGFyZCBsb2NhdGlvbiBtYWtlcyBhYm91dCBhcyBtdWNoIHNlbnNlIGFzIGFyYml0cmFy aWx5IHNheWluZyB0aGF0LCBmb3IgYSBwYXJ0aWN1bGFyIHByb2ZpbGUsIHRoZSBMYXRpbiB3b3Jk IGZvciBzdWJqZWN0IOKAnHN1YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5h bWUgaW5zdGVhZCBvZiDigJxzdWLigJ0uICBZZXMsIGl0IHdpbGwgY29tcGxldGVseSBkaWZmZXJl bnRpYXRlIHRoaXMgcHJvZmlsZSBmcm9tIG90aGVycyBub3Qgc3BlbGxpbmcgdGhlIGNsYWltIG5h bWUgdGhpcyB3YXksIGJ1dCBpdCB3b3VsZCBjZXJ0YWlubHkgYmUgYW4gaW1wZWRpbWVudCB0byB0 aGUgdXNlIG9mIHN0YW5kYXJkIEpXVCBsaWJyYXJpZXMgYW5kIHRvIGludGVyb3BlcmFiaWxpdHku DQoNCklmIHdlIGRlZmluZSB0aGF0IHN1YiBtdXN0IGJlIGF0IHRoZSBldmVudCBsZXZlbCB0aGVu IGl0IGlzIGF0IGEgc3RhbmRhcmQgbG9jYXRpb24sIEkgZG9uJ3Qgc2VlIHdoYXQgdGhlIGlzc3Vl IGlzLiBUaGUgaW1wZWRpbWVudCB5b3UgbWVudGlvbiBpcyB0aGUgYWN0dWFsIHNvbHV0aW9uLiBJ IGRvbid0IHRoaW5rIHRoYXQgYSBKV1QgbGlicmFyeSB0aGF0IHdhcyB3cml0dGVuIGZvciBJZCBU b2tlbnMgc2hvdWxkIGJlIHVzZWQgdG8gcGFyc2UgU0VUcy4gVGhlIGxpYnJhcnkgaGFzIHRvIGJl IFNFVCBhd2FyZSwgaW4gd2hpY2ggY2FzZSB0aGUgZXZlbnQgbGV2ZWwgaXNzK3N1YiBpcyBub3Qg YW4gaXNzdWUgYXQgYWxsLg0KDQoNCg0KDQpGcm9tOiBZYXJvbiBTaGVmZmVyIFttYWlsdG86eWFy b25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+XQ0KU2VudDog U2F0dXJkYXksIEp1bmUgMTcsIDIwMTcgMTo0NSBQTQ0KVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNo ZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj47IE1hcml1cyBTY3VydGVzY3UgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkNjOiBS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBIZW5rIEJpcmtob2x6IDxo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlPj47IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3Jn PG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+OyBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyDQoNCg0KU28gdG8gc3VtbWFyaXplIHdoYXQgSSdtIHNlZWluZyBvbiB0aGlzIHRo cmVhZDoNCg0KRXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRp b24sIHNwZWNpZmljIHJ1bGVzIGZvciAic3ViIiBhbmQgImlzcyIgdGhhdCBjYW4gYmUgZGVmaW5l ZCBpbiB0aGUgU0VUIHNwZWMuDQoNCkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10 ZXJtICJ1c2FnZSIgY2xhaW0gKCJ0eXBlIiBpcyB0YWtlbikgdGhhdCBzaG91bGQgYmUgZGVmaW5l ZCBlbHNld2hlcmUsIGUuZy4gaW4gdGhlIEpXVCBCQ1AuDQoNCkRpZCBJIG1pc3MgYW55dGhpbmc/ DQoNCkJ5IHRoZSB3YXksIGlmIHdlIGRvIGFkZCBhICJ1c2FnZSIgY2xhaW0sIHdlIG5lZWQgdG8g YWxzbyB1c2UgaXQgaW4gdGhlIFNFVCBkb2N1bWVudCBiZWZvcmUgaXQgaXMgcHVibGlzaGVkLg0K DQpUaGFua3MsDQoNCiAgICBZYXJvbg0KDQpPbiAxNS8wNi8xNyAyMjowOCwgSnVzdGluIFJpY2hl ciB3cm90ZToNCisxIHRvIHRoaXMgYXMgd2VsbC4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSnVuIDE1 LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5j b208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQorMSB0byB3aGF0IEFu bmFiZWxsZSBzYWlkLg0KDQpBbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIgcmVx dWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzK3N1YiBw YWlyIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS4NCg0KTWFyaXVzDQoN Ck9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQorMQ0K DQpQaGlsDQoNCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+ PiB3cm90ZToNCk1pa2UsDQoNCllvdXIgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGlzIGlzIGEgbm9u LXByb2JsZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3RzIG9mIGVsZW1lbnRzIG9mIE9w ZW5JRCBDb25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4g QXMgYSByZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGggaXQ6DQoNCjEuICAgICAgIFRo ZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQgY2Fu IGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRv a2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRv IGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLg0KDQoyLiAgICAgICBBbnkgZnV0 dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9i bGVtIGFnYWluLg0KDQozLiAgICAgIE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVz ZSB0aGUgIm5vbmNl4oCdIGNsYWltLg0KDQo0LiAgICAgIFRoaXMgaXMgb25seSBhIHNvbHV0aW9u IGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBwcm9maWxlIHRoYXQgY2FyZXMgYWJvdXQg ZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMgb3duIHNvbHV0aW9uIHRvIHRoZSBwcm9i bGVtLg0KDQpXZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5hbWluZyBjb2xsaXNpb25zIGFu ZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBoYXBwZW4uIFdoYXTigJlzIGJl aW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRoZXNl IHJpc2tzLiBZb3UgYnJvdWdodCB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRpb24g YWN0dWFsbHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24gbGlicmFyaWVzIGZvciBKV1Qg cGFyc2luZy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFyeSBjb3VsZCBoYW5kbGUgZGlz YW1iaWd1YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVhcyB3aXRoIHRoZSBzdGF0dXMg cXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy4NCg0KLS0NCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQtZXZl bnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5 LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRl c2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpDYzogIlJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFu bmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9y ZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9s ekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2Vu IGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpZb3XigJl2ZSBoZWFyZCBvZiDi gJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiAgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9w b3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBt YWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhv dXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBkbyBzby4NCg0KTWFuZGF0b3J5 IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhpcyB0aHJlYWQgdG8gcHJvYmxlbXMg dGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBhY3R1YWxseSBldmVuIGhhdmUuICBJ dOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9y IGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDigJMgc2VlIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQyOC5odG1s PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0Mjgu aHRtbCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JL MTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdH VTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWVLTFRRUG1ZclYzVGhmRGJu OTBTQ3M1NVVST1RQaW5fbGdjNlJkcjVYb3cmZT0+LiAgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93 aW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBU b2tlbnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNp Zmljcywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0gYXBwcm9wcmlhdGUg ZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC4NCg0KVGhlIHByb3Bvc2VkIOKAnHNvbHV0 aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0aGUg bm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2aW91 c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4LiAgWWVzLCB0aGVuIHRoZSBy ZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVu Y2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1 c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuICBUaGUgbW9yZSB1bndpZWxk eSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxvcGVycyBhcmUg dG8ganVzdCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4gIEtlZXBpbmcgaXQgc2lt cGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uICBTdGFuZGFyZHMgYXJlIG9ubHkgdXNlZnVsIGlm IHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNTozMyBQTQ0KVG86IE1hcml1cyBT Y3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFp bHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KQ2M6IElEIEV2ZW50cyBNYWls aW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1 c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hvaW5nIE1hcml1c+KAmXMgcXVlc3Rp b246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT8NCg0KVG8g eW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRo ZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0 IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVj aXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNjZXB0IGEg SldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuDQoNCi0tDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50 IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnPj4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNv bTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEp1bmUgMTMs IDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NCkNj OiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KT24gVHVlLCBK dW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+IHdy b3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFudGljcyB3b3VsZCAidXNhZ2Ui IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEgImludGVuZCIsICJhdWRpZW5j ZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNwZWNpZmllcyB0aGUgdGFyZ2V0 IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tlbiB0byBhdXRo b3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNlY3VyaXR5IGV2 ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoNCkkgZG9uJ3Qga25vdyB3aGF0 IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0KDQoNCg0KDQpIZW5rDQoNCk9u IDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOg0K VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsgdGhlIGFzc3VtcHRp b25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dlIGNhbuKAmXQgZ3VhcmFudGVl IHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhjbHVzaXZlIHNl dCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQgZW5mb3JjaW5n IHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFpbeKAnSBhcHBy b2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBjYW7igJl0IGJl IG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3SXQgaXMgdW5yZWFs aXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVu dCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRh dGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVj YXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50 IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy4NCg0K KzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1ldGVy Lg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCklkZW50aXR5IFNlcnZpY2Vz DQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCipEYXRlOiAqTW9u ZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1hcml1cyBTY3VydGVzY3UgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCipDYzog KkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4+ LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPj4sIElE IEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBp ZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29sdXRp b24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXIN Cg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNjdXNzaW9uIG9u IHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4gMTIsIDIwMTcgYXQgMzoxNSBQ TSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1 cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRoZSBwb2ludGVy IERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUgaXMgZGVzY3JpYmVk IGJ5ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBtaXRpZ2F0aW9uIGlz IGluICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3INCiAg ICBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNlIGRpZmZlcmVudCBz ZXRzIG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJlbnQga2V5cyBmb3Ig ZGlmZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZlcmVudCBpc3N1ZXJz IGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGlsbCB0aGluayB0aGF0 IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kDQogICAgc2Fm ZXR5Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQ TSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtlIGFuZCBJIGp1c3Qg cHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5p bmZvLz9wPTE2OTA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZkPUR3TUdhUSZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZzPWE3WHZaNWpUYnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpNY1VJ VVEmZT0+DQoNCiAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3 ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAg PG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+Pj4gd3Jv dGU6DQoNCiAgICAgICAgICAgIEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMg dG8gYmUgdmVyeSBzaW1pbGFyIHRvDQogICAgICAgICAgICBpZCB0b2tlbnMgYnV0IEkgbm93IHRo aW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi4NCg0KICAgICAgICAgICAgT24gVGh1LCBKdW4gOCwg MjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0 YWtlLmpwPg0KICAgICAgICAgICAgPG1haWx0bzpub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0 YWtlLmpwPj4+IHdyb3RlOg0KDQogICAgICAgICAgICAgICAgKzEgZXNwZWNpYWxseSBmb3IgInR5 cGUiDQoNCiAgICAgICAgICAgICAgICAyMDE3LTA2LTA5IDEwOjMyIEdNVCswOTowMCBQaGlsIEh1 bnQgKElETSkNCiAgICAgICAgICAgICAgICA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbT4+PjoNCg0KICAgICAgICAgICAgICAgICAgICArMQ0KDQogICAg ICAgICAgICAgICAgICAgIFBoaWwNCg0KDQogICAgICAgICAgICAgICAgICAgICA+IE9uIEp1biA4 LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAgICAgICAgICAgICAg IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCiAg ICAgICAgICAgICAgICAgICAgPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbT4+PiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgID4NCiAg ICAgICAgICAgICAgICAgICAgID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24g aG93IHRvDQogICAgICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tl bnMgYW5kIEFjY2VzcyBUb2tlbnMgaW4NCiAgICAgICAgICAgICAgICAgICAgc3VjaCBhIHdheSB0 aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAgICAgICAgICAgICBj b25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5DQogICAgICAgICAg ICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAg ICAgICAgICAgICAgICAgID4gVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJl bWVudDogdGhlDQogICAgICAgICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBt dXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAic3ViIiBpc3N1 ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQogICAgICAgICAgICAg ICAgICAgIHRvIGFuIElkUC4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAg ICAgICAgID4gV2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlDQog ICAgICAgICAgICAgICAgICAgIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgID4gLSBi b3RoICJzdWIiIGFuZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudA0KICAgICAgICAg ICAgICAgICAgICBsZXZlbA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGF0IGV2ZW50 IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbg0KICAgICAgICAgICAgICAgICAgICBiZSBk aWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQgInN1YiIgYXQgZXZl bnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICBhY3Jvc3MgZXZl bnRzIGluIHRoZSBzYW1lIFNFVA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJzdWIiIHNob3Vs ZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAgICAgICAgICBsZXZl bCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUNCiAgICAgICAg ICAgICAgICAgICAgInNob3VsZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAgICAgICAgICAgICAg ID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZm ZXJlbnQgcHJvZmlsZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgZXZlbnQgdHlw ZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAgICAgICAgIHJlbGF0 ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kDQogICAgICAgICAgICAg ICAgICAgIHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWwN CiAgICAgICAgICAgICAgICAgICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmln dWl0eS4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5v dGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAgICAgICAgICAgICAg ICAgICBkZWZpbmUgYSBjb21wb3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmcN CiAgICAgICAgICAgICAgICAgICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0ICBTRVQg aXNzdWVyLiBBbHNvLA0KICAgICAgICAgICAgICAgICAgICBoYXZpbmcgdGhlIHNhbWUgY2xhaW0g bmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRheA0KICAgICAgICAgICAgICAgICAgICBpbiBkaWZm ZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uDQogICAgICAgICAgICAg ICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3Nh bCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3DQogICAgICAgICAgICAgICAgICAgIGNsYWltIGZvciBK V1RzIHRoYXQgZGVmaW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAgICAgICAgICAgICAg ICAgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3QNCiAgICAg ICAgICAgICAgICAgICAgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBi dXQgSSB0aGluaw0KICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldU IGdyb3VwIHNob3VsZCBzZXJpb3VzbHkNCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIuDQog ICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRob3VnaHRzPw0K ICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBNYXJpdXMNCg0K ICAgICAgICAgICAgICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudCBtYWlsaW5nIGxp c3QNCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgIGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdK eFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlS aUhxV2dmeHFtZyZzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0km ZT0NCg0KICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVudCBtYWlsaW5nIGxp c3QNCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50 QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZz4+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9 RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hz aG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRF S2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgSWQtZXZl bnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1 Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQogICAgICAgICAgICAtLQ0KICAgICAgICAg ICAgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfGFkYXdlc0Bnb29nbGUuY29tPG1h aWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4gfCsxIDY1MC0yMTQtMjQxMDx0ZWw6JTJC MSUyMDY1MC0yMTQtMjQxMD4NCiAgICAgICAgICAgIDx0ZWw6KDY1MCklMjAyMTQtMjQxMDx0ZWw6 JTI4NjUwJTI5JTIwMjE0LTI0MTA+Pg0KDQogICAgICAgICAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGlu ZyBsaXN0DQogICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pj4NCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdU bUdNU1dXcyZlPT4NCg0KICAgICAgICAtLQ0KICAgICAgICBTdWJzY3JpYmUgdG8gdGhlIEhBUkRU V0FSRSA8aHR0cDovL2hhcmR0d2FyZS5jb20vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJW ODAmZT0+PiBtYWlsIGxpc3QgdG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3 b3JraW5nIG9uIQ0KDQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6 Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTEx NWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFp bCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBt YWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpq V3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkx MTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50 IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZl bnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NE ZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1Rt R01TV1dzJmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KDQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQNCg0KDQo= --_000_CY4PR21MB0504679FEF878DC7BEDECA9BF5DA0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu Z21haWwtbTIxMzA3ODM5ODg5NDUyNDY1MzVtNDYzOTcxODg5ODY0Nzc0OTY2OG00NDQxNzE0NDQ4 NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1t MjEzMDc4Mzk4ODk0NTI0NjUzNW00NjM5NzE4ODk4NjQ3NzQ5NjY4bTQ0NDE3MTQ0NDg3MjEwNzcw NTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tMjEzMDc4 Mzk4ODk0NTI0NjUzNW00NjM5NzE4ODk4NjQ3NzQ5NjY4bTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5 NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwt bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1bV80NjM5NzE4ODk4NjQ3NzQ5NjY4bTQ0NDE3MTQ0NDg3MjEw NzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAy MDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0MTI5MjI2NDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTI3MjM1ODcyMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5MjMw ODc0MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMzNDA0MDY0O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDINCgl7bXNvLWxpc3QtaWQ6NTIxMTY0MTMyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5MzI4 NzE0MDA7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo1OTU1MjY2NjY7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjYwMjQwNjk1NDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0DQoJe21zby1s aXN0LWlkOjg4MjU5NTI5MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUxMjEwMTA5NDt9DQpA bGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjg4MzQ0Mzc5MjsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTExMzk3ODEzMDI7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDox MjAyNTkzNTU4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAxMjM0NjI1MDt9DQpAbGlzdCBs NjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw2OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjIxMDM0MDk3Mjg7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjI0Mzg0ODA5MDt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw3OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWFyaXVzLCB0aGUg cXVlc3Rpb24g4oCcPC9zcGFuPkRvIHlvdSBoYXZlIGV4YW1wbGVzIG9mIHVzZSBjYXNlcyB0aGF0 IGNhbm5vdCBoYW5kbGUgc3ViIGF0IHRoZSBldmVudCBsZXZlbD88c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+4oCdIGlzIG5vIG1vcmUgdXNlZnVsIHRoYW4gdGhlIHF1ZXN0aW9uIOKAnERvIHlv dSBoYXZlIGV4YW1wbGVzIG9mIHVzZSBjYXNlcyB0aGF0DQogY2Fubm90IGhhbmRsZSDigJhzdWLi gJkgc3BlbGxlZCBhcyB0aGUgTGF0aW4gd29yZCA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPuKAmHN1YmllY3R1beKAmT/igJ0mbmJzcDsgWWVzLCBhcHBsaWNhdGlvbnMgY291bGQg YWx3YXlzIHdvcmsgYXJvdW5kIHRoZSBpbmNvbnZlbmllbmNlcyBpbnRyb2R1Y2VkIGJ5IGFyYml0 cmFyeSBjbGFpbSByZW5hbWluZyBvciByZXBvc2l0aW9uaW5nLCBidXQgdGhleSBzaG91bGRu4oCZ dCBoYXZlIHRvLiZuYnNwOyBJdCBqdXN0IGFkZHMNCiBjb21wbGV4aXR5IGFuZCB3aWxsIGhpbmRl ciBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkl0IHNlZW1z IHRvIG1lIHRoYXQgeW91ciBtb3RpdmF0aW9uIGZvciBhbHdheXMgaGF2aW5nIOKAnHN1YuKAnSBp biB0aGUgZXZlbnQgcGF5bG9hZCwgcmF0aGVyIHRoYW4gYSBub3JtYWwgY2xhaW0sIGlzIHRoYXQg dGhhdOKAmXMgaG93IHlvdSB0aGluayBSSVNDIGV2ZW50cyB3aWxsIGJlIHN0cnVjdHVyZWQsIGFu ZCB0aGF0IHlvdSB3YW50ICo8Yj5hbGw8L2I+KiBldmVudHMNCiB0byBhbHNvIHVzZSB0aGUgUklT QyBldmVudCBzdHJ1Y3R1cmluZy4mbmJzcDsgVG8gbXkgd2F5IG9mIHRoaW5raW5nLCBpZiB5b3Ug cmVhbGx5IGJlbGlldmUgdGhhdCB5b3Ugc2hvdWxkIGJlIGFza2luZyB0aGUgU0VUIHNwZWMgdG8g YmUgd2l0aGRyYXduIGZyb20gdGhlIElFVEYgYW5kIG9ubHkgZGVmaW5lIFJJU0MgZXZlbnRzIGlu IHRoZSBSSVNDIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IEJ1dCBpbiBmYWN0LCByZXF1aXJpbmcgYWxs IGV2ZW50cyB0byBmb2xsb3cgdGhlDQogUklTQyBjb252ZW50aW9ucyBtYWtlcyBubyBtb3JlIHNl bnNlIHRoYW4gcmVxdWlyaW5nIGFsbCBKV1RzIHRvIGJlIElEIFRva2Vucy4mbmJzcDsgVGhhdCB3 b3VsZCBoYXZlIG1hZGUgSldUcyB1c2VsZXNzIGZvciBtYW55IHVzZSBjYXNlcy4mbmJzcDsgUHJv cG9zaW5nIHRvIGxpbWl0IGNsYWltcyB1c2FnZSBpbiBTRVRzIHdvdWxkIGxpa2V3aXNlIG1ha2Ug dGhlbSBpbmFwcGxpY2FibGUgZm9yIG1hbnkgbm9uLVJJU0MgdXNlIGNhc2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+V2UgaGF2ZSBhIHBvdGVudGlhbCBzdWNjZXNzIG9u IG91ciBoYW5kcy4gJm5ic3A7TGV04oCZcyBub3Qgc2NyZXcgaXQgdXAgYnkgbWFraW5nIGl0IHVu bmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFyaXVzIFNjdXJ0ZXNjdSBbbWFpbHRvOm1zY3VydGVzY3VA Z29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcg MTo1MyBQTTxicj4NCjxiPlRvOjwvYj4gTS5MaXphckBPQ0cgJmx0O20ubGl6YXJAb3BlbmNvbnNl bnRncm91cC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7cmlj aGFubmFAYW1hem9uLmNvbSZndDs7IEhlbmsgQmlya2hvbHogJmx0O2hlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGUmZ3Q7OyBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7 OyBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBJRCBFdmVudHMg TWFpbGluZyBMaXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs7DQogUGhpbCBIdW50ICZsdDtw aGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVu dF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNF VCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBKdW4gMjEsIDIwMTcgYXQgMTE6NDYgQU0sIDxhIGhyZWY9Im1haWx0bzpNLkxpemFyQE9D RyI+DQpNLkxpemFyQE9DRzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzptLmxpemFyQG9wZW5jb25z ZW50Z3JvdXAuY29tIiB0YXJnZXQ9Il9ibGFuayI+bS5saXphckBvcGVuY29uc2VudGdyb3VwLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5GV0lX IC0gSSBhZ3JlZSB3aXRoIE1pa2UgdGhhdCBwdXR0aW5nIHJlc3RyaWN0aW9ucyBvbiB0aGUgJnF1 b3Q7c3ViJnF1b3Q7IGNsYWltIHVzYWdlIHdvdWxkIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZSBT RVRzIGZvciBzb21lIHVzZSBjYXNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1YiBpcyBkZWZpbmVk IGFzIG9wdGlvbmFsIGluIEpXVCwgc28gdGVjaG5pY2FsbHkgd2UgYXJlIG5vdCBhZGRpbmcgYW55 IHJlc3RyaWN0aW9ucy4gRG8geW91IGhhdmUgZXhhbXBsZXMgb2YgdXNlIGNhc2VzIHRoYXQgY2Fu bm90IGhhbmRsZSBzdWIgYXQgdGhlIGV2ZW50IGxldmVsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+SXRz IGEgbG90IGVhc2llciB0byBhZGQgdG8gYSBzcGVjIGFuZCB2ZXJ5Jm5ic3A7ZGlmZmljdWx0Jm5i c3A7KGlmIG5vdCBpbXBvc3NpYmxlKSB0byByZXRyYWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYWdyZWUuIEkgZG9uJ3QgdGhpbmsgYW55dGhpbmcgaXMgcmV0cmFjdGVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B Z2Fpbiwgc2VlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlv bi00LjEuMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEu MjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TGFzdCBzZW50ZW5jZSBvZiA0LjEuMiBzdGF0ZXMgJnF1b3Q7VXNlIG9mIHRoaXMgY2xhaW0g aXMgT1BUSU9OQUwuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+SW4gdGhpcyByZWdhcmQsIGtlZXBp bmcgaXQgc2ltcGxlIGlzIGNyaXRpY2FsIGZvciBicm9hZCBhZG9wdGlvbi4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2JhY2tncm91bmQ6d2hpdGUiPk1hcms8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTkgSnVuIDIwMTcsIGF0IDE2OjU1LCBNYXJpdXMgU2N1 cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlLCBhcmUgeW91IHN1Z2dlc3Rp bmcgd2UgZGVmaW5lIFNFVHMgaW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgd2lsbCBub3Qgd29yayBm b3IgUklTQz8gQSB0b3AgbGV2ZWwgaXNzJiM0MztzdWIgaXMgY2xlYXJseSBub3Qgd29ya2luZyBm b3IgUklTQywgYW5kIG1heSBub3Qgd29yayBmb3IgbG9nb3V0IGVpdGhlciBpZiB5b3UgYWxsb3cg bG9nb3V0IHRvIGJlIGluaXRpYXRlZCBmcm9tIGFuIFJQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcml1czxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVuIDE5LCAy MDE3IGF0IDI6MjcgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi Pk1hcml1cywgdGhlcmXigJlzIG5vdGhpbmcgc3RvcHBpbmcgeW91IChvciB0aGUgUklTQyB3b3Jr aW5nIGdyb3VwIG9yIG90aGVyIHByb2ZpbGVzKSBmcm9tIGRlZmluaW5nIGV2ZW50cyB0aGF0IGNh biBiZSBzZW50IGZyb20gUlBzIHRvIElkUHMgbm93LCB3aXRob3V0DQogYW55IGNoYW5nZXMgdG8g dGhlIFNFVCBzcGVjLiZuYnNwOyBTcGVjaWZ5IHRoZSBjbGFpbXMgeW91IHdhbnQgdG8gdXNlLCBh bmQgeW914oCZcmUgZ29sZGVuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPkJ1dCBpdCB3b3VsZCBiZSBjb3VudGVycHJvZHVjdGl2ZSB0byByZXF1aXJlIGFsbCBvdGhl ciBTRVRzIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50cyBvZiB5b3VyIHNwZWNpZmljIHByb2ZpbGUu Jm5ic3A7IFRoZXJlIGFyZSBzaW1wbGVyIHVzZSBjYXNlcyB0aGF0IGNhbg0KIHVzZSBjbGFpbXMg aW4gc2ltcGxlciB3YXlzLiZuYnNwOyBUcnlpbmcgdG8gbWFrZSB0aGUgc2ltcGxlIHVzZSBjYXNl cyBiZSBjb21wbGV4IHdpbGwgaGF2ZSB0aGUgc2lkZSBlZmZlY3Qgb2YgbGltaXRpbmcgdGhlIGFk b3B0aW9uIG9mIHRoZSBzcGVjLCB3aGljaCB3b3VsZG7igJl0IGJlIGdvb2QgZm9yIGFueW9uZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JZiBzdWNjZXNzZnVsLCBT RVRzIHdpbGwgaGF2ZSBtYW55IGRpZmZlcmVudCBwcm9maWxlcy4mbmJzcDsgVGhhdOKAmXMgYSBz aWduIG9mIHN1Y2Nlc3Mg4oCTIG5vdCBhIHNpZ24gb2Ygd2Vha25lc3MuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxhIG5hbWU9Im1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDki PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2E+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1f MjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPjxiPkZyb206PC9iPiBNYXJp dXMgU2N1cnRlc2N1IFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEz MDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9t XzQ2Mzk3MTg4OTg2NDc3NDkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpt XzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBKdW5lIDE5LCAyMDE3IDExOjU4IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtl IEpvbmVzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgz OTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1 X21fNDYzOTcxODg5ODY0Nzc0OSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Om1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpt XzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij55YXJvbmYuaWV0ZkBnbWFp bC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1 MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+Jmd0OzsNCiBKdXN0 aW4gUmljaGVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2 NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+anJpY2hlckBtaXQuZWR1PC9zcGFuPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+ PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUz NV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPiZndDs7DQogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21f NDYzOTcxODg5ODY0Nzc0OSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVf bV80NjM5NzE4ODk4NjQ3NzQ5Ij4mZ3Q7Ow0KIEhlbmsgQmlya2hvbHogJmx0Ozwvc3Bhbj48YSBo cmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYz OTcxODg5ODY0Nzc0OSI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2 NDc3NDkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5 NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExp c3QgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9t XzQ2Mzk3MTg4OTg2NDc3NDkiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PC9z cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9t XzQ2Mzk3MTg4OTg2NDc3NDkiPiZndDs7DQogUGhpbCBIdW50ICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij5w aGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEz MDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5 Ij4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9t XzQ2Mzk3MTg4OTg2NDc3NDkiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBz b2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlz c3VlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUy NDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUy NDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij5PbiBTYXQsIEp1biAxNywgMjAxNyBhdCAyOjA2IFBN LCBNaWtlIEpvbmVzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8y MTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1 MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPiZndDsNCiB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3 MTg4OTg2NDc3NDkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5J4oCZbSBzb3JyeSB0byBi ZSBzbG93IHJlcGx5aW5nIHRvIHNvbWUgbWVzc2FnZXMgaW4gdGhpcyB0aHJlYWQuJm5ic3A7IEkg aGF2ZSBhIGxvdCBvZiBvdGhlcg0KIHRoaW5ncyBvbiBteSBwbGF0ZSwgYnV0IEkgd2lsbCB0YWtl IHRoZSB0aW1lIG5vdyB0byByZXBseSwgYmVjYXVzZSBJIHdob2xlaGVhcnRlZGx5IGRpc2FncmVl IHdpdGggc29tZSBvZiB0aGUgc3RhdGVtZW50cyBiZWxvdyBhbmQgYmVsaWV2ZSBpdCB3b3VsZCBi ZSBzZXZlcmVseSBoYXJtZnVsIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGFuZCBpdHMgYWRvcHRpb24g dG8gYWN0IHVwb24gdGhlbS4mbmJzcDsgU3BlY2lmaWNhbGx5Ojwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7 bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+SSBkaXNhZ3Jl ZSB0aGF0IHNwZWNpZmljIHJ1bGVzIHNob3VsZCBiZSBtYWRlIGZvciB0aGUg4oCcc3Vi4oCdIGNs YWltLiZuYnNwOyBDbGFpbXMgdXNhZ2UgbmVlZHMgdG8gYmUgdXAgdG8gdGhlIGFwcGxpY2F0aW9u LiZuYnNwOyBJIGtub3cgdGhhdCBtYW55IG90aGVycyBhZ3JlZSB3aXRoIG1lLCBiZWNhdXNlIHRo ZSBPcGVuSUQgQ29ubmVjdCB3b3JraW5nDQogZ3JvdXAgZGVzaWduZWQgdGhlIGxvZ291dCB0b2tl biBpbiA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5l Y3QtYmFja2NoYW5uZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9rZW4iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4 OTg2NDc3NDkiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJhY2tjaGFu bmVsLTFfMC0wNC5odG1sI0xvZ291dFRva2VuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4 OTg2NDc3NDkiPg0KICh3aGljaCBpcyBhbHNvIHVzZWQgYXMgYW4gZXhhbXBsZSBpbiA8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQt dG9rZW4tMDEjc2VjdGlvbi0yIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0wMSNzZWN0aW9uLTI8 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80 NjM5NzE4ODk4NjQ3NzQ5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8y MTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+KQ0KIHRvIHVzZSB0aGUg4oCc c3Vi4oCdIGNsYWltIGluIHRoZSBub3JtYWwgd2F5LiZuYnNwOyBQcm9oaWJpdGluZyB0aGlzIHVz YWdlIHdvdWxkIGJlIGEgY29tcGxldGVseSB1bm5lY2Vzc2FyeSBicmVha2luZyBjaGFuZ2Ug4oCT IGFzIGl04oCZcyBpbXBvc3NpYmxlIHRvIGNvbmZ1c2UgYSBsb2dvdXQgdG9rZW4gd2l0aCBhbiBJ RCBUb2tlbiwgZm9yIHJlYXNvbnMgYWxyZWFkeSBjaXRlcyBpbiB0aGlzIHRocmVhZC48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIx MzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij5Tb2x2aW5nIHRoZSBjb25mdXNp b24gaXMgb25lIHByb2JsZW0uIFRoZSBvdGhlciBwcm9ibGVtIEkga2VlcCBtZW50aW9uaW5nIGlz IFNFVHMgaXNzdWVkIGJ5IGFuIFJQIHRvIGJlIHNlbnQNCiB0byBhbiBJZFAuIEhvdyBhcmUgd2Ug c29sdmluZyB0aGF0IHByb2JsZW0gTWlrZT8gSW4gdGhpcyBjYXNlIHRoZSB0b3AgbGV2ZWwgaXNz IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBpc3Mgb2YgdGhlIHN1YiwgYSB0b3AgbGV2ZWwgc3ViIGlz IG5vdCBwb3NzaWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4 OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPkFuZCBJ IGRvbid0IHdhbnQgdG8gZG93bnBsYXkgdGhlIGNvbmZ1c2lvbiBwcm9ibGVtIGVpdGhlci4gSSB0 aGluayBpdCBpcyBhIHJlYWwgY29uY2VybiBhbmQgSSB0aGluayBhIHNvbGlkIHNvbHV0aW9uDQog aXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5 NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+VGhlIE9w ZW5JRCBXb3JraW5nIEdyb3VwIGRlc2lnbmVkIGxvZ291dCB0b2tlbnMgd2l0aG91dCBzZWNldmVu dCBpbiBtaW5kLiBJIGFncmVlIHdlIHNob3VsZCBub3QgcmVja2xlc3NseSBicmVhaw0KIGNvbXBh dGliaWxpdHksIGJ1dCB0byBtZSBpdCBzZWVtcyBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4 ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIw NjA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2 NDc3NDkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjojMDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNiBsZXZlbDEgbGZvMyI+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4 OTg2NDc3NDkiPihJIGFncmVlIHdpdGggdGhlIOKAnGlzc+KAnSBydWxlcyBhbHJlYWR5IGluIHBs YWNlIGF0DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0yLjEiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2 NDc3NDkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRv a2VuLTAxI3NlY3Rpb24tMi4xPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMw NzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PC9zcGFuPjwvYT48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDki Pi4mbmJzcDsNCiBObyBmdXJ0aGVyIOKAnGlzc+KAnSBydWxlcyBhcmUgbmVlZGVkLik8bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIx MzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0 OSI+RnVydGhlciBpc3MgcnVpZXMgYXJlIGFic29sdXRlbHkgbmVlZGVkIGZvciB0aGUgUlAgdG8g SWRQIGNhc2UgZGVzY3JpYmVkIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpt XzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0 Nzc0OSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNCI+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6IzAwMjA2MDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0KPHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3 NzQ5Ij5JdOKAmXMgZmluZSBmb3IgdGhlIOKAnHR5cOKAnSBoZWFkZXIgcGFyYW1ldGVyIHRvIGJl IHVzZWQgZm9yIHNvbWUgcHJvZmlsZXMgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGtpbmRzIG9m IEpXVHMuJm5ic3A7IEl0cyB1c2Ugc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCBpbiB0aGUgU0VUIHNw ZWMuJm5ic3A7IEkgd291bGQgb3Bwb3NlIGR1cGxpY2F0aW5nIHRoZQ0KIOKAnHR5cOKAnSBmdW5j dGlvbmFsaXR5IGJ5IGRlZmluaW5nIGFub3RoZXIgY2xhaW0gd2l0aCBhIGR1cGxpY2F0aXZlIG1l YW5pbmcuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+SWYgdHlw IGNhbiBiZSB1c2UgYW5kIG5vIG90aGVyIGNsYWltIGlzIG5lZWRlZCwgdGhlbiBsZXQncyB0YWxr IGFib3V0IHRoYXQuIEkgZG8gdGhpbmsgU0VUIHNob3VsZCBtYW5kYXRlIGl0Lg0KIEkgZG9uJ3Qg dW5kZXJzdGFuZCB3aHkgbm90LiBDYW4geW91IHBsZWFzZSBwcm9wb3NlIHdpdGggZXhhbXBsZXMg aG93IGNhbiB0eXAgYmUgdXNlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMw NzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDki PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzYiPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpt XzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OiMwMDIwNjA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw3IGxldmVsMSBsZm83Ij4NCjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+ SeKAmWxsIGFsc28gcmVzcG9uZCB0byBBbm5hYmVsbGXigJlzIGFzc2VydGlvbiB0aGF0IOKAnE5v IG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgJnF1b3Q7bm9uY2XigJ0gY2xh aW0u4oCdJm5ic3A7IFRoaXMgcmVmbGVjdHMgYSBtaXN1bmRlcnN0YW5kaW5nLiZuYnNwOyBJdOKA mXMgdGhlICo8Yj52YWx1ZTwvYj4qIG9mIHRoZSBub25jZSB0aGF0IHNlbGYtc2VjdXJlcw0KIHRo ZSBKV1Qg4oCTIG5vdCB0aGF0IGFueSDigJxub25jZeKAnSBjbGFpbSBpcyBwcmVzZW50LiZuYnNw OyBBbnkgYW5kIGFsbCBKV1RzIGNhbiBzaW11bHRhbmVvdXNseSB1c2Ug4oCcbm9uY2XigJ0gd2l0 aG91dCBhbnkgcmlzayBvZiBjb25mbGljdCwgc2luY2UgdGhlIG5vbmNlIHZhbHVlIGlzIGEgY3J5 cHRvZ3JhcGhpY2FsbHkgc2VjdXJlIHJhbmRvbSBudW1iZXIuPG86cD48L286cD48L3NwYW4+PC9s aT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2 NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPkZvciBTRVRzIEkg Y2Fubm90IHNlZSBob3cgdGhlIG5vbmNlIHZhbHVlIGlzIHVzZWZ1bC4gVGhhdCB2YWx1ZSBpcyBu b3QgcGFzc2VkIGJhY2sgYW5kIGl0IGNhbm5vdCBiZSB2ZXJpZmllZC4NCiBPbmx5IHRoZSBwcmVz ZW5jZSBvZiB0aGUgY2xhaW0gY291bGQgaGF2ZSBzb21lIHVzZSwgaGludGluZyBhdCB0aGUgdXNh Z2Ugb2YgdGhlIEpXVCwgYSB2ZXJ5IHdlYWsgc29sdXRpb24gdG8gdGhlIGNvbmZ1c2lvbiBwcm9i bGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVf bV80NjM5NzE4ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNv bG9yOiMwMDIwNjA7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm84Ij4NCjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0 OSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2 Mzk3MTg4OTg2NDc3NDkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDki PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XaWxsIHNvbWUgb2YgeW91IGJlIGF0IHRoZSBD bG91ZCBJZGVudGl0eSBTdW1taXQgbmV4dCB3ZWVrPyZuYnNwOyBJ4oCZZCBiZSBnbGFkIHRvIGhh dmUNCiBpbi1wZXJzb24gZGlzY3Vzc2lvbnMgYWJvdXQgdGhlc2UgdG9waWNzIHRoZXJlLjwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0 OSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5 NzE4ODk4NjQ3NzQ5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UC5TLiZuYnNwOyBGb29kIGZvciB0aG91Z2h0OiZu YnNwOyBQcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSAob3IgYW55IG90aGVyIGNsYWlt KSBvciBmb3JjaW5nDQogaXQgdG8gYmUgbG9jYXRlZCBpbiBhIG5vbi1zdGFuZGFyZCBsb2NhdGlv biBtYWtlcyBhYm91dCBhcyBtdWNoIHNlbnNlIGFzIGFyYml0cmFyaWx5IHNheWluZyB0aGF0LCBm b3IgYSBwYXJ0aWN1bGFyIHByb2ZpbGUsIHRoZSBMYXRpbiB3b3JkIGZvciBzdWJqZWN0IOKAnHN1 YmllY3R1beKAnSBtdXN0IGJlIHVzZWQgYXMgdGhlIGNsYWltIG5hbWUgaW5zdGVhZCBvZiDigJxz dWLigJ0uJm5ic3A7IFllcywgaXQgd2lsbCBjb21wbGV0ZWx5IGRpZmZlcmVudGlhdGUgdGhpcw0K IHByb2ZpbGUgZnJvbSBvdGhlcnMgbm90IHNwZWxsaW5nIHRoZSBjbGFpbSBuYW1lIHRoaXMgd2F5 LCBidXQgaXQgd291bGQgY2VydGFpbmx5IGJlIGFuIGltcGVkaW1lbnQgdG8gdGhlIHVzZSBvZiBz dGFuZGFyZCBKV1QgbGlicmFyaWVzIGFuZCB0byBpbnRlcm9wZXJhYmlsaXR5Ljwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazptXzIxMzA3 ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1X21fNDYzOTcxODg5ODY0Nzc0OSI+ SWYgd2UgZGVmaW5lIHRoYXQgc3ViIG11c3QgYmUgYXQgdGhlIGV2ZW50IGxldmVsIHRoZW4gaXQg aXMgYXQgYSBzdGFuZGFyZCBsb2NhdGlvbiwgSSBkb24ndCBzZWUgd2hhdCB0aGUgaXNzdWUNCiBp cy4gVGhlIGltcGVkaW1lbnQgeW91IG1lbnRpb24gaXMgdGhlIGFjdHVhbCBzb2x1dGlvbi4gSSBk b24ndCB0aGluayB0aGF0IGEgSldUIGxpYnJhcnkgdGhhdCB3YXMgd3JpdHRlbiBmb3IgSWQgVG9r ZW5zIHNob3VsZCBiZSB1c2VkIHRvIHBhcnNlIFNFVHMuIFRoZSBsaWJyYXJ5IGhhcyB0byBiZSBT RVQgYXdhcmUsIGluIHdoaWNoIGNhc2UgdGhlIGV2ZW50IGxldmVsIGlzcyYjNDM7c3ViIGlzIG5v dCBhbiBpc3N1ZSBhdCBhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1fMjEzMDc4 Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazptXzIxMzA3ODM5ODg5NDUyNDY1MzVfbV80NjM5NzE4ODk4NjQ3NzQ5Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1 X21fNDYzOTcxODg5ODY0Nzc0OSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Om1fMjEzMDc4Mzk4ODk0NTI0NjUzNV9tXzQ2Mzk3MTg4OTg2NDc3NDkiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJv bTo8L2I+IFlhcm9uIFNoZWZmZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVuZSAxNywgMjAxNyAxOjQ1IFBNPGJyPg0KPGI+ VG86PC9iPiBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1 IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs7IE1hcml1cyBTY3VydGVz Y3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7OyBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7IEhlbmsgQmly a2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl IiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7 Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs7IFBoaWwg SHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlz dGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD5TbyB0byBzdW1tYXJpemUgd2hhdCBJJ20gc2VlaW5nIG9uIHRoaXMgdGhy ZWFkOjxvOnA+PC9vOnA+PC9wPg0KPHA+RXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNo b3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmljIHJ1bGVzIGZvciAmcXVvdDtzdWImcXVvdDsgYW5k ICZxdW90O2lzcyZxdW90OyB0aGF0IGNhbiBiZSBkZWZpbmVkIGluIHRoZSBTRVQgc3BlYy48bzpw PjwvbzpwPjwvcD4NCjxwPkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICZx dW90O3VzYWdlJnF1b3Q7IGNsYWltICgmcXVvdDt0eXBlJnF1b3Q7IGlzIHRha2VuKSB0aGF0IHNo b3VsZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJDUC48bzpwPjwvbzpw PjwvcD4NCjxwPkRpZCBJIG1pc3MgYW55dGhpbmc/PG86cD48L286cD48L3A+DQo8cD5CeSB0aGUg d2F5LCBpZiB3ZSBkbyBhZGQgYSAmcXVvdDt1c2FnZSZxdW90OyBjbGFpbSwgd2UgbmVlZCB0byBh bHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQuPG86 cD48L286cD48L3A+DQo8cD5UaGFua3MsPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsm bmJzcDsgWWFyb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxNS8wNi8x NyAyMjowOCwgSnVzdGluIFJpY2hlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MSB0byB0aGlzIGFzIHdlbGwuDQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDvigJQgSnVzdGlu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBo cmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0MzsxIHRvIHdoYXQgQW5uYWJlbGxlIHNhaWQuDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCBN aWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIgcmVxdWlyZW1lbnQsIGZvciBSUHMgdG8gc2Vu ZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzJiM0MztzdWIgcGFpciBhdCB0aGUgdG9wIGxldmVs IGlzIGJyb2tlbiBpbiB0aGlzIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWFyaXVzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgSnVu IDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzIx MzA3ODM5ODg5NDUyNDY1MzVtXzQ2Mzk3MTg4OTg2NDc3NDk2NjhtXzQ0NDE3MTQ0NDg3MjEwNzcw NTdtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwt bV8yMTMwNzgzOTg4OTQ1MjQ2NTM1bV80NjM5NzE4ODk4NjQ3NzQ5NjY4bV80NDQxNzE0NDQ4NzIx MDc3MDU3bV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQ TSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5NaWtlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91ciBleHBs YW5hdGlvbiBmb3Igd2h5IHRoaXMgaXMgYSBub24tcHJvYmxlbSBpcyBkZXBlbmRlbnQgdXBvbiBz aWRlIGVmZmVjdHMgb2YgZWxlbWVudHMgb2YgT3BlbklEIENvbm5lY3QgdGhhdCB3ZXJlIG5vdCBk ZXNpZ25lZCB0byBzb2x2ZSB0aGlzIGlzc3VlLiBBcyBhIHJlc3VsdCwgSSBzZWUgc2V2ZXJhbA0K IGlzc3VlcyB3aXRoIGl0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0yMTMwNzgz OTg4OTQ1MjQ2NTM1bTQ2Mzk3MTg4OTg2NDc3NDk2NjhtNDQ0MTcxNDQ0ODcyMTA3NzA1N205MDk0 MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCI+DQoxLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KVGhlIGNhbGxlciBv ZiB0aGUgVG9rZW4gRW5kcG9pbnQgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBjYW4gYmUgY2VydGFp biB0aGF0IGEgbm9uY2UtbGVzcyBJRCBUb2tlbiBpcyByZWFsbHkgYW4gSUQgVG9rZW4uIEFueSBw YXJ0eSB0aGF0IHRoZSBjYWxsZXIgcGFzc2VzIHRoZSBJRCBUb2tlbiBvZmYgdG8gaGFzIG5vIHdh eSB0byB2ZXJpZnkgaXRzIHByb3ZlbmFuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21h aWwtbTIxMzA3ODM5ODg5NDUyNDY1MzVtNDYzOTcxODg5ODY0Nzc0OTY2OG00NDQxNzE0NDQ4NzIx MDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj4NCjIuPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpB bnkgZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhp cyBwcm9ibGVtIGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0yMTMwNzgz OTg4OTQ1MjQ2NTM1bTQ2Mzk3MTg4OTg2NDc3NDk2NjhtNDQ0MTcxNDQ0ODcyMTA3NzA1N205MDk0 MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCI+DQozLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KTm8gb3RoZXIgcHJvZmlsZSBv ZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAmcXVvdDtub25jZeKAnSBjbGFpbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJnbWFpbC1tMjEzMDc4Mzk4ODk0NTI0NjUzNW00NjM5NzE4ODk4NjQ3NzQ5 NjY4bTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3Jh cGgiPg0KNC48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj4NClRoaXMgaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90 aGVyIEpXVCBwcm9maWxlIHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGlu dmVudCBpdHMgb3duIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+V2Uga25vdyBmcm9tIGV4cGVyaWVuY2UgdGhhdCBuYW1pbmcgY29sbGlzaW9ucyBh bmQgcmVwbGF5IGF0dGFja3MgYXJlIGJvdGggdGhpbmdzIHRoYXQgaGFwcGVuLiBXaGF04oCZcyBi ZWluZyBwcm9wb3NlZCBpcyBhIHNpbXBsZSwgZGVmZW5zaXZlIG1lYXN1cmUgYWdhaW5zdCB0aGVz ZSByaXNrcy4gWW91IGJyb3VnaHQNCiB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRp b24gYWN0dWFsbHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24gbGlicmFyaWVzIGZvciBK V1QgcGFyc2luZy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFyeSBjb3VsZCBoYW5kbGUg ZGlzYW1iaWd1YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVhcyB3aXRoIHRoZSBzdGF0 dXMgcXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOg0KPC9iPklkLWV2 ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyBhdCAxOjE2IFBNPGJyPg0K PGI+VG86IDwvYj5NYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZl bnRAaWV0Zi5vcmc8L2E+Jmd0OywgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5rLmJpcmto b2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJ ZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3Rp bmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPllvdeKAmXZlIGhlYXJkIG9mIOKA nHByZW1hdHVyZSBvcHRpbWl6YXRpb27igJ0uJm5ic3A7IEnigJlkIGNoYXJhY3Rlcml6ZSB0aGUg cHJvcG9zYWxzIGluIHRoaXMgdGhyZWFkIGFzIOKAnHByZW1hdHVyZSBwZXNzaW1hdGlvbuKAnSDi gJMgbWFraW5nIHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hvdWxkDQogYmUgc2ltcGxlIGNvbXBsZXgs IHdpdGhvdXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBkbyBzby48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NYW5kYXRvcnkgc29sdXRpb25zIGFy ZSBiZWluZyBwcm9wb3NlZCBpbiB0aGlzIHRocmVhZCB0byBwcm9ibGVtcyB0aGF0IHRoZXJl4oCZ cyBubyBldmlkZW5jZSB0aGF0IHdlIGFjdHVhbGx5IGV2ZW4gaGF2ZS4mbmJzcDsgSXTigJlzIGFs cmVhZHkgYmVlbiBlc3RhYmxpc2hlZA0KIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VU IHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDigJMgc2VlIDxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZhbXA7 ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDtt PVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9ZUtMVFFQ bVlyVjNUaGZEYm45MFNDczU1VVJPVFBpbl9sZ2M2UmRyNVhvdyZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3Vy cmVudC9tc2cwMDQyOC5odG1sPC9hPi4mbmJzcDsgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93aW5n IHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBUb2tl bnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNpZmlj cywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0NCiBhcHByb3ByaWF0ZSBl bmdpbmVlcmluZyBjaG9pY2VzIG9uIG91ciBwYXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPlRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPigJ0sIHN1Y2ggYXMgcHJv aGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1hbCB3YXksIG9yIHJlcXVp cmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNseSBzaW1wbGUgdGhpbmdzIHVu bmVjZXNzYXJpbHkNCiBjb21wbGV4LiZuYnNwOyBZZXMsIHRoZW4gdGhlIHJlc3VsdCBpcyB0aGVu IGRpZmZlcmVudCB0aGFuIGEgbm9ybWFsIEpXVCBidXQgYSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlz IHRoYXQgY3VzdG9tIHBhcnNpbmcgY29kZSB3b3VsZCBoYXZlIHRvIGJlIHVzZWQsIHJhdGhlciB0 aGFuIGEgc3RhbmRhcmQgSldUIHBhcnNlci4mbmJzcDsgVGhlIG1vcmUgdW53aWVsZHkgd2UgbWFr ZSBpdCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVsb3BlcnMgYXJlIHRvDQoganVz dCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4mbmJzcDsgS2VlcGluZyBpdCBzaW1w bGUgaXMgdGhlIGtleSB0byBhZG9wdGlvbi4mbmJzcDsgU3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1 bCBpZiB0aGV5IGFyZSBhY3R1YWxseSB1c2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+RnJvbTo8L2I+IElkLWV2ZW50IFs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGU8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMywgMjAxNyA1OjMzIFBNPGJy Pg0KPGI+VG86PC9iPiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9h PiZndDs7IEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNp dC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZs dDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1l dmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRd IHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQg aXNzdWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RWNob2lu ZyBNYXJpdXPigJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieSDi gJxpbnRlbmTigJ0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyB5b3VyIGZpcnN0IHF1 ZXN0aW9uLCBJIHRoaW5rIGEgYmV0dGVyIGFuYWxvZ3kgd291bGQgYmUgdGhlIFguNTA5IEtleSBV c2FnZSBleHRlbnNpb246IGEgbXVsdGktdmFsdWVkIHByb3BlcnR5IHRoYXQgZGVjbGFyZXMgdGhl IGludGVuZGVkIHB1cnBvc2Ugb2YgdGhlIEpXVCwgYW5kIHRoYXQgYSByZWNpcGllbnQNCiBtYXkg cmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpXVCBiZWluZyBw cmVzZW50ZWQgdG8gaXQgaW4gc29tZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206DQo8L2I+SWQtZXZlbnQgJmx0OzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1 ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2Rh eSwgSnVuZSAxMywgMjAxNyBhdCAxMTowNSBBTTxicj4NCjxiPlRvOiA8L2I+SGVuayBCaXJraG9s eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRh cmdldD0iX2JsYW5rIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+ DQo8Yj5DYzogPC9iPklEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gVHVlLCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2Js YW5rIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIGEgMm5kIHF1ZXN0aW9uLjxicj4NCjxicj4N CldoYXQgc2VtYW50aWNzIHdvdWxkICZxdW90O3VzYWdlJnF1b3Q7IHByb3ZpZGUgdGhhdCB0aGF0 IGFyZSBub3QgY292ZXJlZCB2aWEgJnF1b3Q7aW50ZW5kJnF1b3Q7LCAmcXVvdDthdWRpZW5jZSZx dW90OywgYW5kICZxdW90O3Njb3BlJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O2F1ZCZxdW90OyAoYXVk aWVuY2UpIHNwZWNpZmllcyB0aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQg dXNhZ2UgKGFjY2VzcyB0b2tlbiB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0 byBjb21tdW5pY2F0ZSBhIHNlY3VyaXR5IGV2ZW50Pyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O3Njb3BlJnF1b3Q7IGlzIG5v dCB1c2VkIGJ5IFNFVC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgZG9uJ3Qga25vdyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICZxdW90O2lu dGVuZCZxdW90OyAob3IgaW50ZW50KT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KSGVuazxicj4NCjxicj4NCk9uIDA2LzEzLzIwMTcg MDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyITxicj4N Cjxicj4NCkkgdGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2Vk Ojxicj4NCjxicj4NCsK3V2UgY2Fu4oCZdCBndWFyYW50ZWUgdGhhdCBldmVyeSB0eXBlIG9mIEpX VCB3aWxsIGhhdmUgYSBtdXR1YWxseSBleGNsdXNpdmUgc2V0IG9mIHZhbGlkIGNsYWltcyBhbmQv b3IgaGVhZGVyIHBhcmFtZXRlcnMsIGFuZCBlbmZvcmNpbmcgdGhpcyByZXF1aXJlcyBhIOKAnGZh aWwgb24gYW4gdW5yZWNvZ25pemVkIGNsYWlt4oCdIGFwcHJvYWNoIHRvIGVuc3VyZSB0aGF0IEpX VHMgZnJvbSBzb21lIGZ1dHVyZSBzcGVjIGNhbuKAmXQgYmUgbWlzdGFrZW4gZm9yIEpXVHMNCiBm cm9tIGEgY3VycmVudCBzcGVjLjxicj4NCjxicj4NCsK3SXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhw ZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZvciBk aWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBz cGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2lu ZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50IGtleXMuPGJyPg0K PGJyPg0KwrdEaXR0byBmb3Ig4oCcYXVk4oCdIGFuZCDigJxpc3PigJ0gY2xhaW1zLjxicj4NCjxi cj4NCiYjNDM7MSBmb3IgYSDigJx0eXBl4oCdIG9yIOKAnHVzYWdl4oCdIGNsYWltL2hlYWRlciBw YXJhbWV0ZXIuPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbjxicj4NCjxicj4NCklkZW50aXR5IFNlcnZpY2VzPGJyPg0KPGJyPg0KKkZyb206ICpJZC1l dmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDs8YnI+DQoqRGF0ZTogKk1v bmRheSwgSnVuZSAxMiwgMjAxNyBhdCAzOjE4IFBNPGJyPg0KKlRvOiAqTWFyaXVzIFNjdXJ0ZXNj dSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KKkNjOiAqQWRhbSBEYXdlcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRh d2VzQGdvb2dsZS5jb208L2E+Jmd0OywgJnF1b3Q7bWF0YWtlLCBub3YmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+bm92QG1hdGFrZS5qcDwv YT4mZ3Q7LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7LA0K ICZxdW90O1BoaWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0 Ozxicj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBU b2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8YnI+DQo8YnI+DQpBZ3JlZWQu IE5vdGUgdGhhdCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hhdCBzaG91 bGQgYmUgaW4gMy45Ljxicj4NCjxicj4NCk9uIE1vbiwgSnVuIDEyLCAyMDE3IGF0IDM6MTUgUE0s IE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1z Y3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IFRoYW5rcyBmb3IgdGhlIHBvaW50ZXIgRGljaywgdmVyeSBnb29kIHRpbWluZyA6LSk8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBpc3N1ZSBpcyBkZXNjcmliZWQgYnkgJnF1b3Q7 Mi43LiBDcm9zcy1KV1QgQ29uZnVzaW9uJnF1b3Q7IGFuZCB0aGU8YnI+DQombmJzcDsgJm5ic3A7 IG1pdGlnYXRpb24gaXMgaW4gJnF1b3Q7My45LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZlIFZhbGlk YXRpb24gUnVsZXMgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyBEaWZmZXJlbnQgS2luZHMgb2YgSldU cyZxdW90Oywgc3BlY2lmaWNhbGx5ICZxdW90O1VzZSBkaWZmZXJlbnQgc2V0cyBvZjxicj4NCiZu YnNwOyAmbmJzcDsgcmVxdWlyZWQgY2xhaW1zLi4uJnF1b3Q7LCAmcXVvdDtVc2UgZGlmZmVyZW50 IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgSldUcy4mcXVv dDsgYW5kICZxdW90O1VzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9m IEpXVHMuJnF1b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBzdGlsbCB0aGluayB0aGF0 IGEgJnF1b3Q7dHlwZSZxdW90OyBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFu ZDxicj4NCiZuYnNwOyAmbmJzcDsgc2FmZXR5Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgTWFyaXVzPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0 IDk6NTkgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPjxicj4NCiZuYnNw OyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFyb24sIE1pa2UgYW5kIEkg anVzdCBwdWJsaXNoZWQgYW4gQkNQIElEIGZvciBKV1Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHAtM0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZhbXA7ZD1Ed01HYVEm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9YTdYdlo1alRidEEydmpm YUhJTWJ2RU9wU0JCbEJwZHNEa0lUWk1jVUlVUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE2OTA8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTowMiBQTSBBZGFtIERhd2Vz ICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5h ZGF3ZXNAZ29vZ2xlLmNvbTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHdhcyBpbml0aWFsbHkgYSBmYW4g b2Yga2VlcGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkIHRva2VucyBidXQgSSBub3cgdGhpbmsgdGhp cyBpcyBhIGJldHRlciBwbGFuLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBtYXRha2UsIG5v diAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5rIj5ub3ZA bWF0YWtlLmpwPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2Js YW5rIj5ub3ZAbWF0YWtlLmpwPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxIGVz cGVjaWFsbHkgZm9yICZxdW90O3R5cGUmcXVvdDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMTctMDYtMDkgMTA6MzIg R01UJiM0MzswOTowMCBQaGlsIEh1bnQgKElETSk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7Jmd0Ozo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzsxPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBoaWw8YnI+DQo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBPbiBKdW4gOCwgMjAxNywgYXQgNjoyOCBQ TSwgTWFyaXVzIFNjdXJ0ZXNjdTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xl LmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsm Z3Q7IHdyb3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsgVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2Vz cyBUb2tlbnMgaW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxl bWVudGF0aW9ucyB3aWxsIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25mdXNlIG9uZSBmb3IgdGhl IG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZ1bG5lcmFiaWxp dGllcy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IFRoZXJlIGlzIGFsc28gYW5vdGhlciBpbXBvcnRhbnQgcmVxdWlyZW1lbnQ6IHRoZTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBTRVQgaXNzdWVyIGluIHNvbWUgY2FzZXMgbXVzdCBiZSBkaWZmZXJl bnQgZnJvbSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3ViJnF1b3Q7IGlzc3Vlci4gVGhp cyBpcyB0aGUgY2FzZSBvZiBhbiBSUCBzZW5kaW5nIFNFVHM8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8g YW4gSWRQLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgV2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGZvbGxvd2luZzo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAt IGJvdGggJnF1b3Q7c3ViJnF1b3Q7IGFuZCAmcXVvdDtpc3MmcXVvdDsgdG8gYmUgZGVmaW5lZCBh dCB0aGUgZXZlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyAtICZxdW90O2lzcyZxdW90OyBhdCBldmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBs ZXZlbCBjYW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmUgZGlmZmVyZW50PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsgLSAmcXVvdDtpc3MmcXVvdDsgYW5kICZxdW90O3N1YiZxdW90OyBhdCBldmVu dCBsZXZlbCBjYW4gYmUgZGlmZmVyZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFjcm9zcyBldmVudHMg aW4gdGhlIHNhbWUgU0VUPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSAmcXVvdDtzdWIm cXVvdDsgc2hvdWxkIE5PVCBiZSBwcmVzZW50IGF0IHRoZSB0b3AgU0VUPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGxldmVsICh0aGlzIHNvbHZlcyB0aGUgZGlzYW1iaWd1YXRpb24pLCBwbGVhc2Ugbm90ZTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzaG91bGQmcXVvdDsgYW5kIG5vdCAmcXVvdDttdXN0JnF1 b3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBUaGlzIHNvbHV0aW9uIGFsc28gYWxsb3dzIGRpZmZlcmVudCBwcm9maWxlcyB0aGF0PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGRlZmluZSBldmVudCB0eXBlcyB0byBkZWZpbmUgYWRkaXRpb25hbCBj bGFpbXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVsYXRlZCB0byBzdWIgKGxpa2UgZW1haWwgb3IgcGhv bmVfbnVtYmVyKSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3 aWxsIGJlIGF0IHRoZSBldmVudCBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVyZSB3aWxsIGJl IG5vIGNvbGxpc2lvbnMgb3IgYW1iaWd1aXR5Ljxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgQW5vdGhlciBwcm9wb3NhbCAod2hpY2ggSSBz dXBwb3J0ZWQpIHdhcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWZpbmUgYSBjb21wb3NpdGUgJnF1 b3Q7YXVkJnF1b3Q7IGNsYWltLiBUaGlzIGlzIG5vdCBzb2x2aW5nPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHRoZSByZXF1aXJlbWVudCBmb3IgYSBkaXN0aW5jdCZuYnNwOyBTRVQgaXNzdWVyLiBBbHNvLDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBoYXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcgZGlmZmVy ZW50IHN5bnRheDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbiBkaWZmZXJlbnQgdG9rZW4gdHlwZXMgY291 bGQgbGVhZCB0byBjb25mdXNpb24uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBBbmQgeWV0IGFub3RoZXIgcHJvcG9zYWwgd2FzIHRvIGlu dHJvZHVjZSBhIG5ldzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjbGFpbSBmb3IgSldUcyB0aGF0IGRlZmlu ZXMgYSAmcXVvdDt0eXBlJnF1b3Q7LiBUaGlzIGlzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcmFj dGljYWwgaW4gdGhlIHNob3J0IHRlcm0sIGFuZCBpdCBhbHNvIGlzIG5vdDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBzb2x2aW5nIHRoZSBkaXN0aW5jdCBpc3N1ZXIgcmVxdWlyZW1lbnQsIGJ1dCBJIHRoaW5r PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHRoaXMgaXMgc29tZXRoaW5nIHRoZSBKV1QgZ3JvdXAgc2hvdWxk IHNlcmlvdXNseTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25zaWRlci48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRob3VnaHRzPzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgTWFyaXVz PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBJ ZC1ldmVudCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7DQo8YSBocmVmPSJtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4gJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smYW1wO209Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZh bXA7cz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZhbXA7cz01eFFx dkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmFtcDtlPTwvYT48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1l dmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZh bXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudDwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9h PiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NE ZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29N VTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfDxh IGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bn b29nbGUuY29tPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+Jmd0OyB8PGEgaHJlZj0idGVsOiUyQjElMjA2 NTAtMjE0LTI0MTAiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzEgNjUwLTIxNC0yNDEwPC9hPjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJ0 ZWw6JTI4NjUwJTI5JTIwMjE0LTI0MTAiIHRhcmdldD0iX2JsYW5rIj50ZWw6KDY1MCklMjAyMTQt MjQxMDwvYT4mZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1l dmVudEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJ VFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhD c0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3 b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLS0gPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YnNj cmliZSB0byB0aGUgSEFSRFRXQVJFICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FR JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9 SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dV N0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWk3NVV3OGFlaFl2bHBJ Wk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJWODAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2hhcmR0d2FyZS5jb20vPC9hPiZndDsNCiBtYWlsIGxpc3QgdG88YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxi cj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NClN1YnNjcmliZSB0byB0aGUgSEFS RFRXQVJFICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9y UU9VWDJYTVlCZXJWODAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2hhcmR0d2FyZS5j b20vPC9hPiZndDsNCiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3Jr aW5nIG9uITxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZh bXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtz PVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4 QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtz PVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9PC9hPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZl bnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5JZC1ldmVudCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5JZC1ldmVudEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5J ZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0504679FEF878DC7BEDECA9BF5DA0CY4PR21MB0504namp_-- From nobody Wed Jun 21 13:34:28 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AC41294A3 for ; Wed, 21 Jun 2017 13:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br-6ugQRDhX9 for ; Wed, 21 Jun 2017 13:34:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7D5129484 for ; Wed, 21 Jun 2017 13:34:21 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5LKYFqT011831 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 20:34:16 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5LKYFlL026082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 20:34:15 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5LKYBwv012008; Wed, 21 Jun 2017 20:34:11 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jun 2017 13:34:10 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-1B730730-7E1C-4174-8488-8B82C31BC286 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 21 Jun 2017 13:34:07 -0700 Cc: Marius Scurtescu , "M.Lizar@OCG" , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <04C1DB58-C70A-4B5D-8E17-D2D017CCBE5E@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39! @mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> To: Mike Jones X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:34:26 -0000 --Apple-Mail-1B730730-7E1C-4174-8488-8B82C31BC286 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike It also includes how i think scim and logout should be structures.=20 How is consistency so that any party can issue complex? If we stick with the currently narrow scoped backchannel logout draft we cre= ate a lot of complexity for everyone else. Namely that backchannel will requ= ire special handling.=20 If risc issues logouts they will be different.=20 Phil > On Jun 21, 2017, at 1:19 PM, Mike Jones wrot= e: >=20 > Marius, the question =E2=80=9CDo you have examples of use cases that canno= t handle sub at the event level?=E2=80=9D is no more useful than the questio= n =E2=80=9CDo you have examples of use cases that cannot handle =E2=80=98sub= =E2=80=99 spelled as the Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D Y= es, applications could always work around the inconveniences introduced by a= rbitrary claim renaming or repositioning, but they shouldn=E2=80=99t have to= . It just adds complexity and will hinder adoption. > =20 > It seems to me that your motivation for always having =E2=80=9Csub=E2=80=9D= in the event payload, rather than a normal claim, is that that=E2=80=99s ho= w you think RISC events will be structured, and that you want *all* events t= o also use the RISC event structuring. To my way of thinking, if you really= believe that you should be asking the SET spec to be withdrawn from the IET= F and only define RISC events in the RISC working group. But in fact, requi= ring all events to follow the RISC conventions makes no more sense than requ= iring all JWTs to be ID Tokens. That would have made JWTs useless for many u= se cases. Proposing to limit claims usage in SETs would likewise make them i= napplicable for many non-RISC use cases. > =20 > We have a potential success on our hands. Let=E2=80=99s not screw it up b= y making it unnecessarily complicated. > =20 > -- Mike > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Wednesday, June 21, 2017 1:53 PM > To: M.Lizar@OCG > Cc: Mike Jones ; Richard Backman, Annabelle <= richanna@amazon.com>; Henk Birkholz ; Justi= n Richer ; Yaron Sheffer ; ID Events= Mailing List ; Phil Hunt > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG wrote: > FWIW - I agree with Mike that putting restrictions on the "sub" claim usag= e would unnecessarily complicate SETs for some use cases. > =20 > sub is defined as optional in JWT, so technically we are not adding any re= strictions. Do you have examples of use cases that cannot handle sub at the e= vent level? > =20 > =20 > =20 > Its a lot easier to add to a spec and very difficult (if not impossible) t= o retract. > =20 > I agree. I don't think anything is retracted. > =20 > Again, see: > https://tools.ietf.org/html/rfc7519#section-4.1.2 > =20 > Last sentence of 4.1.2 states "Use of this claim is OPTIONAL." > =20 > =20 > In this regard, keeping it simple is critical for broad adoption.=20 > =20 > Mark > =20 > On 19 Jun 2017, at 16:55, Marius Scurtescu wrote: > =20 > Mike, are you suggesting we define SETs in such a way that they will not w= ork for RISC? A top level iss+sub is clearly not working for RISC, and may n= ot work for logout either if you allow logout to be initiated from an RP. >=20 > Marius > =20 > On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones w= rote: > Marius, there=E2=80=99s nothing stopping you (or the RISC working group or= other profiles) from defining events that can be sent from RPs to IdPs now,= without any changes to the SET spec. Specify the claims you want to use, a= nd you=E2=80=99re golden. > =20 > But it would be counterproductive to require all other SETs to meet the re= quirements of your specific profile. There are simpler use cases that can u= se claims in simpler ways. Trying to make the simple use cases be complex w= ill have the side effect of limiting the adoption of the spec, which wouldn=E2= =80=99t be good for anyone. > =20 > If successful, SETs will have many different profiles. That=E2=80=99s a s= ign of success =E2=80=93 not a sign of weakness. > =20 > -- Mike > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Monday, June 19, 2017 11:58 AM > To: Mike Jones > Cc: Yaron Sheffer ; Justin Richer = ; Richard Backman, Annabelle ; Henk Birkholz ; ID Events Mailing List ; Phil Hu= nt >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > =20 > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones w= rote: > I=E2=80=99m sorry to be slow replying to some messages in this thread. I h= ave a lot of other things on my plate, but I will take the time now to reply= , because I wholeheartedly disagree with some of the statements below and be= lieve it would be severely harmful to the specification and its adoption to a= ct upon them. Specifically: > =20 > I disagree that specific rules should be made for the =E2=80=9Csub=E2=80=9D= claim. Claims usage needs to be up to the application. I know that many o= thers agree with me, because the OpenID Connect working group designed the l= ogout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.htm= l#LogoutToken (which is also used as an example in https://tools.ietf.org/ht= ml/draft-ietf-secevent-token-01#section-2) to use the =E2=80=9Csub=E2=80=9D c= laim in the normal way. Prohibiting this usage would be a completely unnece= ssary breaking change =E2=80=93 as it=E2=80=99s impossible to confuse a logo= ut token with an ID Token, for reasons already cites in this thread. > Solving the confusion is one problem. The other problem I keep mentioning i= s SETs issued by an RP to be sent to an IdP. How are we solving that problem= Mike? In this case the top level iss is different from the iss of the sub, a= top level sub is not possible. > =20 > And I don't want to downplay the confusion problem either. I think it is a= real concern and I think a solid solution is important. > =20 > The OpenID Working Group designed logout tokens without secevent in mind. I= agree we should not recklessly break compatibility, but to me it seems nece= ssary in this case. > =20 > =20 > =20 > (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at https://= tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1. No further =E2= =80=9Ciss=E2=80=9D rules are needed.) > =20 > Further iss ruies are absolutely needed for the RP to IdP case described a= bove. > =20 > =20 > =20 > =20 > It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be use= d for some profiles to differentiate between kinds of JWTs. Its use should n= ot be mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D functionality by defining another claim with a duplicative meaning= . > If typ can be use and no other claim is needed, then let's talk about that= . I do think SET should mandate it. I don't understand why not. Can you plea= se propose with examples how can typ be used? > =20 > =20 > =20 > =20 > I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CN= o other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D Thi= s reflects a misunderstanding. It=E2=80=99s the *value* of the nonce that s= elf-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is p= resent. Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D wit= hout any risk of conflict, since the nonce value is a cryptographically secu= re random number. > =20 > For SETs I cannot see how the nonce value is useful. That value is not pas= sed back and it cannot be verified. Only the presence of the claim could hav= e some use, hinting at the usage of the JWT, a very weak solution to the con= fusion problem. > =20 > =20 > =20 > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d b= e glad to have in-person discussions about these topics there. > =20 > -- Mike > =20 > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or a= ny other claim) or forcing it to be located in a non-standard location makes= about as much sense as arbitrarily saying that, for a particular profile, t= he Latin word for subject =E2=80=9Csubiectum=E2=80=9D must be used as the cl= aim name instead of =E2=80=9Csub=E2=80=9D. Yes, it will completely differen= tiate this profile from others not spelling the claim name this way, but it w= ould certainly be an impediment to the use of standard JWT libraries and to i= nteroperability. > =20 > If we define that sub must be at the event level then it is at a standard l= ocation, I don't see what the issue is. The impediment you mention is the ac= tual solution. I don't think that a JWT library that was written for Id Toke= ns should be used to parse SETs. The library has to be SET aware, in which c= ase the event level iss+sub is not an issue at all. > =20 > =20 > =20 > =20 > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 > Sent: Saturday, June 17, 2017 1:45 PM > To: Justin Richer ; Marius Scurtescu > Cc: Richard Backman, Annabelle ; Mike Jones ; Henk Birkholz ; ID Ev= ents Mailing List ; Phil Hunt >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > So to summarize what I'm seeing on this thread: >=20 > Everybody agrees with Marius's short-term solution, specific rules for "su= b" and "iss" that can be defined in the SET spec. >=20 > Almost everybody agrees on a long-term "usage" claim ("type" is taken) tha= t should be defined elsewhere, e.g. in the JWT BCP. >=20 > Did I miss anything? >=20 > By the way, if we do add a "usage" claim, we need to also use it in the SE= T document before it is published. >=20 > Thanks, >=20 > Yaron >=20 > =20 > On 15/06/17 22:08, Justin Richer wrote: > +1 to this as well. > =20 > =E2=80=94 Justin > =20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu wrot= e: > =20 > +1 to what Annabelle said. > =20 > Also, Mike you are missing the other requirement, for RPs to send events t= o an IdP. The iss+sub pair at the top level is broken in this case. >=20 > Marius > =20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wr= ote: > +1 > =20 > Phil >=20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >=20 > Mike, > =20 > Your explanation for why this is a non-problem is dependent upon side effe= cts of elements of OpenID Connect that were not designed to solve this issue= . As a result, I see several issues with it: > 1. The caller of the Token Endpoint is the only party that can be ce= rtain that a nonce-less ID Token is really an ID Token. Any party that the c= aller passes the ID Token off to has no way to verify its provenance. >=20 > 2. Any future ID Token distribution method needs to solve this probl= em again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile tha= t cares about disambiguation has to invent its own solution to the problem. >=20 > =20 > We know from experience that naming collisions and replay attacks are both= things that happen. What=E2=80=99s being proposed is a simple, defensive me= asure against these risks. You brought up JWT libraries: a general solution a= ctually makes it easier to use common libraries for JWT parsing. A =E2=80=9C= usage-aware=E2=80=9D JWT library could handle disambiguation for any JWT pro= file, whereas with the status quo each profile would require unique logic. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Mike Jones > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > Cc: "Richard Backman, Annabelle" , ID Events Mailing L= ist , Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2=80= =99d characterize the proposals in this thread as =E2=80=9Cpremature pessima= tion=E2=80=9D =E2=80=93 making things that can and should be simple complex,= without data showing there=E2=80=99s any need to do so. > =20 > Mandatory solutions are being proposed in this thread to problems that the= re=E2=80=99s no evidence that we actually even have. It=E2=80=99s already b= een established that it=E2=80=99s impossible for a SET to be confused for an= ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/curre= nt/msg00428.html. If people have data showing that this is possible with sp= ecific kinds of Access Tokens or other real JWT deployments, please provide s= pecifics, so that we can use that data to inform appropriate engineering cho= ices on our part. > =20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2= =80=9Csub=E2=80=9D in the normal way, or requiring a type claim, would make p= reviously simple things unnecessarily complex. Yes, then the result is then= different than a normal JWT but a consequence of this is that custom parsin= g code would have to be used, rather than a standard JWT parser. The more u= nwieldy we make it to use SETs, the more likely developers are to just creat= e their own data structures. Keeping it simple is the key to adoption. Sta= ndards are only useful if they are actually used. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Bac= kman, Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu ; Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80= =9Cintend=E2=80=9D? > =20 > To your first question, I think a better analogy would be the X.509 Key Us= age extension: a multi-valued property that declares the intended purpose of= the JWT, and that a recipient may refer to when determining whether to acce= pt a JWT being presented to it in some context. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event on behalf of Marius Scurtescu <= mscurtescu@google.com> > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer > =20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via "intend= ", "audience", and "scope"? > =20 > "aud" (audience) specifies the target client, but not the intended usage (= access token to authorize resource access or SET to communicate a security e= vent?) > =20 > "scope" is not used by SET. > =20 > I don't know what do you mean by "intend" (or intent)? > =20 > =20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutual= ly exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ens= ure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a= current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cd= ifferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is e= asier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header pa= rameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event on behalf of Dick Hardt > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID Ev= ents Mailing List , "Phil Hunt (IDM)" > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and disti= nct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be in 3= .9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: >=20 > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YK= OCd0mxPQFJLhxWI&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j= 746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D= =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 > =20 --Apple-Mail-1B730730-7E1C-4174-8488-8B82C31BC286 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mike

It also includes how i think sci= m and logout should be structures. 

How is consistency so that any par= ty can issue complex?

If we stick with the currently narrow scoped backchanne= l logout draft we create a lot of complexity for everyone else. Namely that b= ackchannel will require special handling. 

If risc issues logouts they= will be different. 

Phil
=

On Jun 21, 2017, at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Marius, the question =E2= =80=9CDo you have examples of use cases that cannot handle sub at the= event level?=E2=80=9D is no more useful than t= he question =E2=80=9CDo you have examples of use cases that cannot handle =E2=80=98sub=E2=80=99 spelled as the Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D  Yes, appl= ications could always work around the inconveniences introduced by arbitrary= claim renaming or repositioning, but they shouldn=E2=80=99t have to.  I= t just adds complexity and will hinder adoption.

 

It seems to me that you= r motivation for always having =E2=80=9Csub=E2=80=9D in the event payload, r= ather than a normal claim, is that that=E2=80=99s how you think RISC events w= ill be structured, and that you want *all* events to also use the RISC event structuring.  To my way of thinking, if you= really believe that you should be asking the SET spec to be withdrawn from t= he IETF and only define RISC events in the RISC working group.  But in f= act, requiring all events to follow the RISC conventions makes no more sense than requiring all JWTs to be ID Token= s.  That would have made JWTs useless for many use cases.  Proposi= ng to limit claims usage in SETs would likewise make them inapplicable for m= any non-RISC use cases.

 

We have a potential suc= cess on our hands.  Let=E2=80=99s not screw it up by making it unnecess= arily complicated.

 

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

 

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Wednesday, June 21, 2017 1:53 PM
To: M.Lizar@OCG <m= .lizar@openconsentgroup.com>
Cc: Mike Jones <Mic= hael.Jones@microsoft.com>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de">henk.birkholz@sit.fraunhof= er.de>; Justin Richer <jricher@= mit.edu>; Yaron Sheffer <= yaronf.ietf@gmail.com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com<= /a>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG <m.lizar@openconsentgroup.com> wrote:

FWIW - I agree with Mike that putt= ing restrictions on the "sub" claim usage would unnecessarily complicate SET= s for some use cases.

 

sub is defined as optional in JWT, so technically we a= re not adding any restrictions. Do you have examples of use cases that canno= t handle sub at the event level?

 

 

 

Its= a lot easier to add to a spec and very difficult (if not impossib= le) to retract.

 

I agree. I don't think anything is retracted.

 

Again, see:

 

Last sentence of 4.1.2 states "Use of this claim is O= PTIONAL."

 

 

In t= his regard, keeping it simple is critical for broad adoption. 

 

Mar= k

 

On 19 Jun 2017, at 16:55, Marius Scurtescu <mscurtescu@google.com> wrote:

 

Mike, are you suggesting we define SETs in such a way= that they will not work for RISC? A top level iss+sub is clearly not workin= g for RISC, and may not work for logout either if you allow logout to be ini= tiated from an RP.


Marius

 

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

Marius, there=E2=80=99s nothing stoppi= ng you (or the RISC working group or other profiles) from defining events th= at can be sent from RPs to IdPs now, without any changes to the SET spec.  Specify the claims you want to use, and y= ou=E2=80=99re golden.

 

But it would be counterproductive to r= equire all other SETs to meet the requirements of your specific profile.&nbs= p; There are simpler use cases that can use claims in simpler ways.  Trying to make the simple use cases be co= mplex will have the side effect of limiting the adoption of the spec, which w= ouldn=E2=80=99t be good for anyone.

 

If successful, SETs will have many dif= ferent profiles.  That=E2=80=99s a sign of success =E2=80=93 not a sign= of weakness.

 

      &n= bsp;            =             &nbs= p;            &n= bsp;          -- Mike

 

From: Marius Scurtescu [mailto:mscurtescu@google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Justin Richer <jri= cher@mit.edu>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <ph= il.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

 

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <Michael.Jones@microsoft.com<= /a>>= ; wrote:

I=E2=80=99m sorry to be slow replying to som= e messages in this thread.  I have a lot of other things on my plate, but I will take the time now to reply, because I wholeh= eartedly disagree with some of the statements below and believe it would be s= everely harmful to the specification and its adoption to act upon them. = ; Specifically:

 

Solving the confusion is one problem. The other problem I keep mentioning i= s SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top level= iss is different from the iss of the sub, a top level sub is not possible.<= o:p>

 

And I don't want to downplay the confusion problem either. I think it is a= real concern and I think a solid solution is important.

 

The OpenID Working Group designed logout tokens without secevent in mind. I= agree we should not recklessly break compatibility, but to me it seems necessary in this case.=

 

  •  =

 

 

Further iss ruies are absolutely needed for the RP to IdP case described a= bove.

 

 

  •  =

 

  • It=E2=80= =99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used for some= profiles to differentiate between kinds of JWTs.  Its use should not b= e mandated in the SET spec.  I would oppose duplicating the =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a duplic= ative meaning.

If typ can be use and no other claim is needed, then let's talk about that= . I do think SET should mandate it. I don't understand why not. Can you please propose with examples how can ty= p be used?

 

 

  •  =

 

  • I=E2=80= =99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo other p= rofile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D  This re= flects a misunderstanding.  It=E2=80=99s the *value* of the nonc= e that self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is present.&nb= sp; Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D without a= ny risk of conflict, since the nonce value is a cryptographically secure ran= dom number.

 

For SETs I cannot see how the nonce value is useful. That value is not pas= sed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage of= the JWT, a very weak solution to the confusion problem.

 

  •  =

 

Will some of you be at the Cloud Identity Su= mmit next week?  I=E2=80=99d be glad to have in-person discussions about these topics there.

 

       &n= bsp;            =             &nbs= p;            &n= bsp;         -- Mike

 

P.S.  Food for thought:  Prohibiti= ng the use of =E2=80=9Csub=E2=80=9D (or any other claim) or forcing it to be located in a non-standard location makes about as much sense as ar= bitrarily saying that, for a particular profile, the Latin word for subject =E2= =80=9Csubiectum=E2=80=9D must be used as the claim name instead of =E2=80=9C= sub=E2=80=9D.  Yes, it will completely differentiate this profile from others not spelling the claim name this way, but it would cert= ainly be an impediment to the use of standard JWT libraries and to interoper= ability.

 

If we define that sub must be at the event level then it is at a standard l= ocation, I don't see what the issue is. The impediment you mention is the actual solution. I don't think that a= JWT library that was written for Id Tokens should be used to parse SETs. Th= e library has to be SET aware, in which case the event level iss+sub is not a= n issue at all.

 

 

 

 

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscurtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@microso= ft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules for "s= ub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) th= at should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use it in the S= ET document before it is published.

Thanks,

    Yaron

 

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

 

 =E2=80=94 Justin

 

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote= :

 

+1 to what Annabelle said.

 

Also, Mike you are missing the other requirement, for RPs to send ev= ents to an IdP. The iss+sub pair at the top level is broken in this case.


Marius

 

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrot= e:

+1

 

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= o:p>

Mike,

 

Your explanation for why this is a non-problem is dependent upon sid= e effects of elements of OpenID Connect that were not designed to solve this= issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can be certain that a= nonce-less ID Token is really an ID Token. Any party that the caller passes= the ID Token off to has no way to verify its provenance.

2.       Any future ID Token distribution method needs to solve this problem again.

3.      No other profile of JWT can ever use the "nonce=E2=80=9D claim.

4.      This is only a solution for ID Tokens. Every other JWT profile that cares ab= out disambiguation has to invent its own solution to the problem.=

 

We know from experience that naming collisions and replay attacks ar= e both things that happen. What=E2=80=99s being proposed is a simple, defens= ive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common= libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library coul= d handle disambiguation for any JWT profile, whereas with the status quo eac= h profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microso= ft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List= <id-event@ietf.or= g>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

You=E2=80=99ve heard of =E2=80=9Cprema= ture optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in t= his thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making thing= s that can and should be simple complex, without data showing there=E2=80=99s any need to do so.<= /span>

 

Mandatory solutions are being proposed= in this thread to problems that there=E2=80=99s no evidence that we actuall= y even have.  It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80= =93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.&nb= sp; If people have data showing that this is possible with specific kinds of= Access Tokens or other real JWT deployments, please provide specifics, so t= hat we can use that data to inform appropriate engineering choices on our part.

 

The proposed =E2=80=9Csolutions=E2=80=9D= , such as prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, or= requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but= a consequence of this is that custom parsing code would have to be used, ra= ther than a standard JWT parser.  The more unwieldy we make it to use S= ETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key t= o adoption.  Standards are only useful if they are actually used.

 

      &n= bsp;            =             &nbs= p;            &n= bsp;   -- Mike

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.f= raunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D?

 

To your first question, I think a better analogy would be the X.509 K= ey Usage extension: a multi-valued property that declares the intended purpo= se of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it= in some context.

 

-- 

Annabelle Richard Backman

Identity Services

 

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com= >
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunh= ofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend",= "audience", and "scope"?

 

"aud" (audience) specifies the target client, but not the intended u= sage (access token to authorize resource access or SET to communicate a secu= rity event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by "intend" (or intent)?

 

 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutually= exclusive set of valid claims and/or header parameters, and enforcing this r= equires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure= that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdif= ferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by t= he spec or not, implementers will ignore this because managing one key is ea= sier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header para= meter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <= adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9= .

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.c= om>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the     mitigation is in "3.9. Use Mutually Exclusive Validation Rules= for
    Different Kinds of JWTs", specifically "Use different sets of<= br>     required claims...", "Use different keys for different kinds o= f
    JWTs." and "Use different issuers for different kinds of JWTs.= ".

    I still think that a "type" claim would bring a lot of clarity= and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID for J= WT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com         <mailto:adawes@google.com>> wrote:

            I was initially a fan of keeping S= ETS to be very similar to
            id tokens but I now think this is a= better plan.

            On Thu, Jun 8, 2017 at 6:56 PM mat= ake, nov <nov@matake.j= p
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "t= ype"

                2017-06-09 10:32 GMT= +09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com <mailt= o:phil.hunt@oracle= .com>>:

                    +1
=
                    Phil

                     = > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <mscurtescu@google.c= om

                   = ; <mailto:mscu= rtescu@google.com>> wrote:
                     = >
                     = > There were a couple of proposals on how to
                    distin= guish SETs from Id Tokens and Access Tokens in
                    such a= way that naive implementations will not
                    confus= e one for the other and open up security
                    vulner= abilities.
                     = >
                     = > There is also another important requirement: the
                    SET is= suer in some cases must be different from the
                    "sub" i= ssuer. This is the case of an RP sending SETs
                    to an I= dP.
                     = >
                     = > With these requirements in mind I propose the
                    follow= ing:
                     = > - both "sub" and "iss" to be defined at the event
                    level<= br>                      = > - "iss" at event level and at top SET level can
                    be dif= ferent
                     = > - "iss" and "sub" at event level can be different
                    across= events in the same SET
                     = > - "sub" should NOT be present at the top SET
                    level (= this solves the disambiguation), please note
                    "shoul= d" and not "must"
                     = >
                     = > This solution also allows different profiles that
                    define= event types to define additional claims
                    relate= d to sub (like email or phone_number) and
                    since a= ll these claims will be at the event level
                    there w= ill be no collisions or ambiguity.
                     = >
                     = > Another proposal (which I supported) was to
                    define= a composite "aud" claim. This is not solving
                    the re= quirement for a distinct  SET issuer. Also,
                    having= the same claim name having different syntax
                    in dif= ferent token types could lead to confusion.
                     = >
                     = > And yet another proposal was to introduce a new
                    claim f= or JWTs that defines a "type". This is not
                    practi= cal in the short term, and it also is not
                    solvin= g the distinct issuer requirement, but I think
                    this i= s something the JWT group should seriously
                    consid= er.
                     = >
                     = > Thoughts?
                     = >
                     = > Marius

                     = > _______________________________________________
                     = > Id-event mailing list

                    &nbs= p;> Id-event@ietf.org= <mailto:Id-event@= ietf.org>
                     = >
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_= listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk= KY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuut= Bx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKO= Cd0mxPQFJLhxWI&e=3D

                    ______= _________________________________________
                    Id-eve= nt mailing list
                    Id-event@ietf.org <m= ailto:Id-event@ietf.o= rg>
                    https://www.ietf.org/mailman/listinfo/id-event

                ____________________= ___________________________
                Id-event mailing lis= t
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            --
            Adam Dawes | Sr. Product Manager |= adawes@google.com=
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            __________________________________= _____________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        --
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.c= om/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 

 

_______________________________________________
Id-event mailing list
Id-event@ietf.or=
g
https://www.ietf.=
org/mailman/listinfo/id-event

 

 

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org/m= ailman/listinfo/id-event

 

 

= --Apple-Mail-1B730730-7E1C-4174-8488-8B82C31BC286-- From nobody Wed Jun 21 13:38:21 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B5E129410 for ; Wed, 21 Jun 2017 13:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0jO0KLt6s7Q for ; Wed, 21 Jun 2017 13:38:06 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFD71294A2 for ; Wed, 21 Jun 2017 13:38:05 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id p21so20435208qke.3 for ; Wed, 21 Jun 2017 13:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y+kyKYPMjIIQpMuErLOUJTh5nDJ0dalXDEmi59Yj2i4=; b=IzuRj7OIaBGMbXST3nyZylfCJCjbXuQzhBdBXpXwidKXoC6+0woNMe6zoG9rVaamzC HYVWvLsKvuSFAis7Yb9kOpt+oz4kGKJrVEKRxO1Ub9tvJSLnHCgfoDZdoc02HVy6KKJ4 +xTAV4ymlUEHsHfDCIvU/B7IKvpQBno9QFfM34btzIFGJIjTDa+oNo22RDMeW+GQrM6D c/eU1pj4cg9U8qNg44BuZdORNSpFxOWzuzeHFFSEa6b7vUMojmj3mZ+ks175LWsxTjEQ O5cvWAQvqlApbOQ7+Fecneu9BXTVLb7Dt3keZUbPhg+K4kewlgx8yQ3CMJ6MfePvRPwc HuBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y+kyKYPMjIIQpMuErLOUJTh5nDJ0dalXDEmi59Yj2i4=; b=jNkm9FVFgOsg5jTKjXKZDt9tFdwh04qDMnVXvyQ5ZnBuQdPIzXAlX1SkGRATJXpJ1J f1POTknVF/SvD3d/jKvMEiLX36O9olMmnA3zVQ48TsYNKGeoJU92Q/tIlNjCwEycJxHq yo3aUZ7QS7rX7SsN4InNIzdYo5u4lx4lEK/EQTZ2mh/n4jBe3Sk41xrLH9mYuSON58bS sRDpAH5mXru0IFC+uIUmxU86mLEmAUVdZv+bh47r957FGX5keP6McUjFT/HNIzwvVo78 JP89+ootMOHOBMTAhVWbQvLJPH8bnPOOXPo0PVZ/GsexOXHOUR04YU9FnwWjxf3Uf8aX A/tw== X-Gm-Message-State: AKS2vOyD/RRqxYtV75kQ8/0nJBVoBtKYU20jzgXYhj3GT8HbvfW337oZ FBCd/aSSzXCYhVu48nd1yRqbVqY+Yg== X-Received: by 10.55.79.198 with SMTP id d189mr19298030qkb.37.1498077484908; Wed, 21 Jun 2017 13:38:04 -0700 (PDT) MIME-Version: 1.0 References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <04C1DB58-C70A-4B5D-8E17-D2D017CCBE5E@oracle.com> In-Reply-To: <04C1DB58-C70A-4B5D-8E17-D2D017CCBE5E@oracle.com> From: Nat Sakimura Date: Wed, 21 Jun 2017 20:37:54 +0000 Message-ID: To: "Phil Hunt (IDM)" , Mike Jones Cc: "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Marius Scurtescu , Yaron Sheffer , "M.Lizar@OCG" , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a114a728855860d05527e585e" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:38:20 -0000 --001a114a728855860d05527e585e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inferring the message type by the presence of a parameter is a bad practice. We should use "typ" header parameter to express it explicitly, e.g., "typ":"sevent+jwt" which is an abbreviation of "application/sevent+jwt". We should not put restrictions on "sub" or any other claims. On Thu, Jun 22, 2017 at 5:34 AM Phil Hunt (IDM) wrote: > Mike > > It also includes how i think scim and logout should be structures. > > How is consistency so that any party can issue complex? > > If we stick with the currently narrow scoped backchannel logout draft we > create a lot of complexity for everyone else. Namely that backchannel wil= l > require special handling. > > If risc issues logouts they will be different. > > Phil > > On Jun 21, 2017, at 1:19 PM, Mike Jones > wrote: > > Marius, the question =E2=80=9CDo you have examples of use cases that cann= ot > handle sub at the event level?=E2=80=9D is no more useful than the questi= on =E2=80=9CDo > you have examples of use cases that cannot handle =E2=80=98sub=E2=80=99 s= pelled as the > Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D Yes, applications could= always work around the > inconveniences introduced by arbitrary claim renaming or repositioning, b= ut > they shouldn=E2=80=99t have to. It just adds complexity and will hinder = adoption. > > > > It seems to me that your motivation for always having =E2=80=9Csub=E2=80= =9D in the event > payload, rather than a normal claim, is that that=E2=80=99s how you think= RISC > events will be structured, and that you want **all** events to also use > the RISC event structuring. To my way of thinking, if you really believe > that you should be asking the SET spec to be withdrawn from the IETF and > only define RISC events in the RISC working group. But in fact, requirin= g > all events to follow the RISC conventions makes no more sense than > requiring all JWTs to be ID Tokens. That would have made JWTs useless fo= r > many use cases. Proposing to limit claims usage in SETs would likewise > make them inapplicable for many non-RISC use cases. > > > > We have a potential success on our hands. Let=E2=80=99s not screw it up = by making > it unnecessarily complicated. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com > ] > > *Sent:* Wednesday, June 21, 2017 1:53 PM > *To:* M.Lizar@OCG > *Cc:* Mike Jones ; Richard Backman, > Annabelle ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>; Justin Richer ; Yaron > Sheffer ; ID Events Mailing List ; > Phil Hunt > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG < > m.lizar@openconsentgroup.com> wrote: > > FWIW - I agree with Mike that putting restrictions on the "sub" claim > usage would unnecessarily complicate SETs for some use cases. > > > > sub is defined as optional in JWT, so technically we are not adding any > restrictions. Do you have examples of use cases that cannot handle sub at > the event level? > > > > > > > > Its a lot easier to add to a spec and very difficult (if not impossible) > to retract. > > > > I agree. I don't think anything is retracted. > > > > Again, see: > > https://tools.ietf.org/html/rfc7519#section-4.1.2 > > > > > Last sentence of 4.1.2 states "Use of this claim is OPTIONAL." > > > > > > In this regard, keeping it simple is critical for broad adoption. > > > > Mark > > > > On 19 Jun 2017, at 16:55, Marius Scurtescu wrote: > > > > Mike, are you suggesting we define SETs in such a way that they will not > work for RISC? A top level iss+sub is clearly not working for RISC, and m= ay > not work for logout either if you allow logout to be initiated from an RP= . > > > Marius > > > > On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones > wrote: > > Marius, there=E2=80=99s nothing stopping you (or the RISC working group o= r other > profiles) from defining events that can be sent from RPs to IdPs now, > without any changes to the SET spec. Specify the claims you want to use, > and you=E2=80=99re golden. > > > > But it would be counterproductive to require all other SETs to meet the > requirements of your specific profile. There are simpler use cases that > can use claims in simpler ways. Trying to make the simple use cases be > complex will have the side effect of limiting the adoption of the spec, > which wouldn=E2=80=99t be good for anyone. > > > > If successful, SETs will have many different profiles. That=E2=80=99s a = sign of > success =E2=80=93 not a sign of weakness. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Monday, June 19, 2017 11:58 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Justin Richer < > jricher@mit.edu>; Richard Backman, Annabelle ; Henk > Birkholz ; ID Events Mailing List < > id-event@ietf.org>; Phil Hunt > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > > > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones > wrote: > > I=E2=80=99m sorry to be slow replying to some messages in this thread. I= have a > lot of other things on my plate, but I will take the time now to reply, > because I wholeheartedly disagree with some of the statements below and > believe it would be severely harmful to the specification and its adoptio= n > to act upon them. Specifically: > > > > - I disagree that specific rules should be made for the =E2=80=9Csub= =E2=80=9D claim. > Claims usage needs to be up to the application. I know that many othe= rs > agree with me, because the OpenID Connect working group designed the l= ogout > token in > http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutT= oken > > (which is also used as an example in > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 > ) > to use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibiting= this usage would be > a completely unnecessary breaking change =E2=80=93 as it=E2=80=99s imp= ossible to confuse a > logout token with an ID Token, for reasons already cites in this threa= d. > > Solving the confusion is one problem. The other problem I keep mentioning > is SETs issued by an RP to be sent to an IdP. How are we solving that > problem Mike? In this case the top level iss is different from the iss of > the sub, a top level sub is not possible. > > > > And I don't want to downplay the confusion problem either. I think it is = a > real concern and I think a solid solution is important. > > > > The OpenID Working Group designed logout tokens without secevent in mind. > I agree we should not recklessly break compatibility, but to me it seems > necessary in this case. > > > > > - > > > > - (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 > . > No further =E2=80=9Ciss=E2=80=9D rules are needed.) > > > > Further iss ruies are absolutely needed for the RP to IdP case described > above. > > > > > > > - > > > > - It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to = be used for some > profiles to differentiate between kinds of JWTs. Its use should not b= e > mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D > functionality by defining another claim with a duplicative meaning. > > If typ can be use and no other claim is needed, then let's talk about > that. I do think SET should mandate it. I don't understand why not. Can y= ou > please propose with examples how can typ be used? > > > > > > > - > > > > - I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of > JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D This reflects a = misunderstanding. > It=E2=80=99s the **value** of the nonce that self-secures the JWT =E2= =80=93 not that > any =E2=80=9Cnonce=E2=80=9D claim is present. Any and all JWTs can si= multaneously use > =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a > cryptographically secure random number. > > > > For SETs I cannot see how the nonce value is useful. That value is not > passed back and it cannot be verified. Only the presence of the claim cou= ld > have some use, hinting at the usage of the JWT, a very weak solution to t= he > confusion problem. > > > > > - > > > > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d = be glad > to have in-person discussions about these topics there. > > > > -- Mike > > > > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or= any other claim) > or forcing it to be located in a non-standard location makes about as muc= h > sense as arbitrarily saying that, for a particular profile, the Latin wor= d > for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name in= stead of =E2=80=9Csub=E2=80=9D. > Yes, it will completely differentiate this profile from others not spelli= ng > the claim name this way, but it would certainly be an impediment to the u= se > of standard JWT libraries and to interoperability. > > > > If we define that sub must be at the event level then it is at a standard > location, I don't see what the issue is. The impediment you mention is th= e > actual solution. I don't think that a JWT library that was written for Id > Tokens should be used to parse SETs. The library has to be SET aware, in > which case the event level iss+sub is not an issue at all. > > > > > > > > > > *From:* Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > *Sent:* Saturday, June 17, 2017 1:45 PM > *To:* Justin Richer ; Marius Scurtescu < > mscurtescu@google.com> > *Cc:* Richard Backman, Annabelle ; Mike Jones < > Michael.Jones@microsoft.com>; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List < > id-event@ietf.org>; Phil Hunt > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AU= Lcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI= &e=3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQ= l7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs= &e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --001a114a728855860d05527e585e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inferring the message type by the presence of a parameter = is a bad practice. We should use "typ" header parameter to expres= s it explicitly, e.g., "typ":"sevent+jwt" which is an a= bbreviation of "application/sevent+jwt". We should not put restri= ctions on "sub" or any other claims.=C2=A0

On Thu, Jun 22, 2017 at 5:34 AM Phil Hunt (I= DM) <phil.hunt@oracle.com>= ; wrote:
Mik= e

It also includes how i think = scim and logout should be structures.=C2=A0

How is consistency so that any party can issue complex?
<= div id=3D"m_7165540287873991571AppleMailSignature">
If we stick with the currently narrow= scoped backchannel logout draft we create a lot of complexity for everyone= else. Namely that backchannel will require special handling.=C2=A0

If risc issues logouts they will be di= fferent.=C2=A0
Phil

On Jun 21, 2017, at 1:19 PM, Mike Jones <Michael.Jones@microso= ft.com> wrote:

Marius, the question = =E2=80=9CDo you have examples of use cases that cannot handle sub at= the event level?=E2=80=9D is no more useful = than the question =E2=80=9CDo you have examples of use cases that cannot handle =E2=80=98sub=E2=80=99 spelled as the Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D=C2=A0 Yes, a= pplications could always work around the inconveniences introduced by arbit= rary claim renaming or repositioning, but they shouldn=E2=80=99t have to.= =C2=A0 It just adds complexity and will hinder adoption.

=C2=A0

It seems to me that yo= ur motivation for always having =E2=80=9Csub=E2=80=9D in the event payload,= rather than a normal claim, is that that=E2=80=99s how you think RISC even= ts will be structured, and that you want *all* events to also use the RISC event structuring.=C2=A0 To my way of thinking, if yo= u really believe that you should be asking the SET spec to be withdrawn fro= m the IETF and only define RISC events in the RISC working group.=C2=A0 But= in fact, requiring all events to follow the RISC conventions makes no more sense than requiring all JWTs to be ID Toke= ns.=C2=A0 That would have made JWTs useless for many use cases.=C2=A0 Propo= sing to limit claims usage in SETs would likewise make them inapplicable fo= r many non-RISC use cases.

=C2=A0

We have a potential su= ccess on our hands.=C2=A0 Let=E2=80=99s not screw it up by making it unnece= ssarily complicated.

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mailto:mscurtescu@google.com]


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG <m.lizar@openconsentgroup.com> wrote:

FWIW - I agree with Mike that pu= tting restrictions on the "sub" claim usage would unnecessarily c= omplicate SETs for some use cases.

=C2=A0

sub is defined as optional in JWT, so technically we= are not adding any restrictions. Do you have examples of use cases that ca= nnot handle sub at the event level?

=C2=A0

=C2=A0

=C2=A0

It= s a lot easier to add to a spec and very=C2=A0difficult=C2=A0(if not imposs= ible) to retract.

=C2=A0

I agree. I don't think anything is retracted.=

=C2=A0

Again, see:

=C2=A0

Last sentence of 4.1.2 states "Use of this clai= m is OPTIONAL."

=C2=A0

=C2=A0

In= this regard, keeping it simple is critical for broad adoption.=C2=A0

=C2=A0

Ma= rk

=C2=A0

On 19 Jun 2017, at 16:55, Marius Scurtescu <mscurtescu@google.com= > wrote:

=C2=A0

Mike, are you suggesting we define SETs in such a wa= y that they will not work for RISC? A top level iss+sub is clearly not work= ing for RISC, and may not work for logout either if you allow logout to be = initiated from an RP.


Marius

=C2=A0

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Marius, there=E2=80=99= s nothing stopping you (or the RISC working group or other profiles) from d= efining events that can be sent from RPs to IdPs now, without any changes to the SET spec.=C2=A0 Specify the claims you want to use, and= you=E2=80=99re golden.

=C2=A0

But it would be counte= rproductive to require all other SETs to meet the requirements of your spec= ific profile.=C2=A0 There are simpler use cases that can use claims in simpler ways.=C2=A0 Trying to make the simple use cases be c= omplex will have the side effect of limiting the adoption of the spec, whic= h wouldn=E2=80=99t be good for anyone.

=C2=A0

If successful, SETs wi= ll have many different profiles.=C2=A0 That=E2=80=99s a sign of success =E2= =80=93 not a sign of weakness.

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mailto:<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank">mscurtescu@= google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Justin Richer <jricher@mit.edu>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>=


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

=C2=A0

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones &l= t;<= span>Michael.Jones@microsoft.com> wrote:

I=E2=80=99m sorr= y to be slow replying to some messages in this thread.=C2=A0 I have a lot o= f other things on my plate, but I will take the time now to reply, because I whole= heartedly disagree with some of the statements below and believe it would b= e severely harmful to the specification and its adoption to act upon them.= =C2=A0 Specifically:

=C2=A0=

Solving the confusion is one problem. The othe= r problem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top leve= l iss is different from the iss of the sub, a top level sub is not possible= .

=C2=A0

And I don't want to downplay the confusion= problem either. I think it is a real concern and I think a solid solution is important.

=C2=A0

The OpenID Working Group designed logout token= s without secevent in mind. I agree we should not recklessly break compatibility, but to me it seems necessary in this case.

=C2=A0

  • =C2=A0

=C2=A0=

=C2=A0

Further iss ruies are absolutely needed for th= e RP to IdP case described above.

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0=

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to b= e used for some profiles to differentiate between kinds of JWTs.=C2=A0 Its = use should not be mandated in the SET spec.=C2=A0 I would oppose duplicatin= g the =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a dupli= cative meaning.

If typ can be use and no other claim is needed= , then let's talk about that. I do think SET should mandate it. I don't understand why not. Can you please propose with examples how c= an typ be used?

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0=

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of JWT can ever use the "nonce=E2=80=9D claim.= =E2=80=9D=C2=A0 This reflects a misunderstanding.=C2=A0 It=E2=80=99s the *<= b>value* of the nonce that self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is present.= =C2=A0 Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D with= out any risk of conflict, since the nonce value is a cryptographically secu= re random number.

=C2=A0

For SETs I cannot see how the nonce value is u= seful. That value is not passed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage o= f the JWT, a very weak solution to the confusion problem.

=C2=A0

  • =C2=A0

=C2=A0=

Will some of you= be at the Cloud Identity Summit next week?=C2=A0 I=E2=80=99d be glad to ha= ve in-person discussions about these topics there.

=C2=A0=

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

=C2=A0=

P.S.=C2=A0 Food = for thought:=C2=A0 Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any oth= er claim) or forcing it to be located in a non-standard location makes about as much sense as a= rbitrarily saying that, for a particular profile, the Latin word for subjec= t =E2=80=9Csubiectum=E2=80=9D must be used as the claim name instead of =E2= =80=9Csub=E2=80=9D.=C2=A0 Yes, it will completely differentiate this profile from others not spelling the claim name this way, but it would cer= tainly be an impediment to the use of standard JWT libraries and to interop= erability.

=C2=A0

If we define that sub must be at the event lev= el then it is at a standard location, I don't see what the issue is. The impediment you mention is the actual solution. I don't think t= hat a JWT library that was written for Id Tokens should be used to parse SE= Ts. The library has to be SET aware, in which case the event level iss+sub = is not an issue at all.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscurtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike Jones <Michael.Jones@mic= rosoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com><= /p>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules f= or "sub" and "iss" that can be defined in the SET spec.=

Almost everybody agrees on a long-term "usage" claim ("ty= pe" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use = it in the SET document before it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.= com> wrote:

=C2=A0

+1 to what Annabelle said.

=C2=A0

Also, Mike you are missing the other requirement, fo= r RPs to send events to an IdP. The iss+sub pair at the top level is broken= in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <= ;phil.hunt@oracle= .com> wrote:

+1

=C2=A0

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote= :

Mike,

=C2=A0

Your explanation for why this is a non-problem is de= pendent upon side effects of elements of OpenID Connect that were not desig= ned to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certain that= a nonce-less ID Token is really an ID Token. Any party that the caller pas= ses the ID Token off to has no way to verify its provenance.<= /p>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem again.<= u>

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim.=

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that cares a= bout disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and r= eplay attacks are both things that happen. What=E2=80=99s being proposed is= a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use commo= n libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library co= uld handle disambiguation for any JWT profile, whereas with the status quo = each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@mic= rosoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events = Mailing List <id-= event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>=
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

You=E2=80=99ve heard o= f =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d characterize = the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2= =80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0

Mandatory solutions ar= e being proposed in this thread to problems that there=E2=80=99s no evidenc= e that we actually even have.=C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.= =C2=A0 If people have data showing that this is possible with specific kind= s of Access Tokens or other real JWT deployments, please provide specifics,= so that we can use that data to inform appropriate engineering choices on our part.

=C2=A0

The proposed =E2=80=9C= solutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80=9D in= the normal way, or requiring a type claim, would make previously simple th= ings unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain w= hat you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better analogy wou= ld be the X.509 Key Usage extension: a multi-valued property that declares = the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to i= t in some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.= com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank">henk.bi= rkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target clie= nt, but not the intended usage (access token to authorize resource access o= r SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.<= /p>

=C2=A0

I don't know what do you mean by "intend&qu= ot; (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com<= /a>>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing Li= st <id-event@ietf= .org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:= mscurtescu@googl= e.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank">adawes@google.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake= .jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com <mai= lto:phil.hunt@ora= cle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank">mscurtescu@google= .com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:mscurtescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-event@ietf.org <mailto:Id-even= t@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YT= pkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJm= uutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn8= 8YKOCd0mxPQFJLhxWI&e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <= ;mailto:Id-event@iet= f.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________________= ______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtw= are.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event

=C2=A0

=C2=A0

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event

=C2=A0

=C2=A0<= /p> 

_______________________________________________
Id-event mailing list
Id-event@ietf.o=
rg
https://www.=
ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.= org/mailman/listinfo/id-event

=C2=A0

=C2=A0

____________________________________________= ___
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114a728855860d05527e585e-- From nobody Wed Jun 21 13:39:41 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CF0129410 for ; Wed, 21 Jun 2017 13:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2stdVIA18SMR for ; Wed, 21 Jun 2017 13:39:35 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00E612420B for ; Wed, 21 Jun 2017 13:39:34 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m47so9979078iti.0 for ; Wed, 21 Jun 2017 13:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2fuZj0HYo7ygfjX0f7aR40lgqdh9BsWDBzh864SuIaQ=; b=PhyFDMWbO13q2+63EaMGF0GKotIY5snv+MlApF1VljYSZVOpux6tpmByHXNQlxzCE5 dPdpqL70760xrAtP3IVUBxRWSCcfut+oftTkHl7+Qnd62zGHL+ugoEuJF9OhU7h3EynC 4ubHzISHKSWp0GNjHjGTHZ4FhVfcB66wb47dtzz0cYxYDAfR+ExPKV2vMDuQymiT5RCM 1SgQKT2WnTg0WRjVv0hPDufL3aoUlLxQwId+0fvDAOkkOYITQ7DJ1wFpw3x2rYbu5Ypv /FEsM6wCKb2svkErsgB+jeJWxz327Q5I1mb+95um2GzfcS/s7NgXDjFG6pACnD/FY9pD Vlbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2fuZj0HYo7ygfjX0f7aR40lgqdh9BsWDBzh864SuIaQ=; b=gAlBurOR4nhN9iNDOkitFk+UB0ANmmD1TIjD4BvZR6LXoXCK8bm2bBK302dNBskXCL 2gc//nMveHZXpvKp9VP1Oz0Q1ooluqoI/i8PRRCuikxidGOKZubBNX5cQ8LXDbbqDfXy Y+Id3l+EW9U9I6nL9tOxVk3crHnaQRdAm55WGyb/Sc8DnmMWGi9MwRHcPO83aRB/4Y3k Jkva0tpYHuiRwnJyGjNbc2NBky0rO9fi8d2gxDYZ8iDkcmgQ0cqBTID76pQQNMtdAywi xKDlQ7cmhpXSsY4MPSBzCrFPrS5Mcsen8GfDce97Wm1VoJilEE3lw6yg87VgrWu/pA4c eGxg== X-Gm-Message-State: AKS2vOzCUViAKCUgfRbnJUFMd3W4IpMK24a7Sf+43uc8KGRu5ilVt7WE URS/yHBbdi9gHdXO X-Received: by 10.36.64.147 with SMTP id n141mr11290620ita.101.1498077573740; Wed, 21 Jun 2017 13:39:33 -0700 (PDT) Received: from [10.150.72.61] ([208.59.64.22]) by smtp.gmail.com with ESMTPSA id e4sm1783224ioe.50.2017.06.21.13.39.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 13:39:32 -0700 (PDT) From: John Bradley Message-Id: <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 21 Jun 2017 15:39:32 -0500 In-Reply-To: <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> Cc: Justin Richer , Marius Scurtescu , Annabelle Richard , Phil Hunt , Michael Jones , ID Events Mailing List , Henk Birkholz To: Yaron Sheffer References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11352a32a7f3bb05527e5d11" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:39:39 -0000 --001a11352a32a7f3bb05527e5d11 Content-Type: multipart/alternative; boundary="Apple-Mail=_29D70A81-1E2C-41D0-901B-C8E65BA02BAC" --Apple-Mail=_29D70A81-1E2C-41D0-901B-C8E65BA02BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the envelope typ is a media/mime type. Registering = application/idt+jwt if we register jwt as a structured name sufix. =20 Using the cty is also possible. I need to think about what is better = but we can agree on a convention. Not everything is going to be a set token like not every JWS is a JWT. If we are going to define processing rules to stop collisions and = confusion around JWT for different purposes, we should just start using = the typ parameter based on the existing spec. In general content sniffing if there is more than one option eventually = gets you into trouble. I am not convinced that forcing there to be no sub at the top level is a = good idea. =20 It is not the way we should differentiate between SET and id_tokens. If sub is not allowed at the top level people will do non SET JWT for = things where the subject is scoped to the iss of the token. I think defining sub to be part of the event for cases where the sub is = scoped differently from the issuer of the token is fine, but should not = be required for all event types. I think we should solve the confusion issue separately from the sub = issue. Sorry I am at CIS so trying to catch up on lists. John B. > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer = wrote: >=20 > So to summarize what I'm seeing on this thread: >=20 > Everybody agrees with Marius's short-term solution, specific rules for = "sub" and "iss" that can be defined in the SET spec. >=20 > Almost everybody agrees on a long-term "usage" claim ("type" is taken) = that should be defined elsewhere, e.g. in the JWT BCP. > Did I miss anything? >=20 > By the way, if we do add a "usage" claim, we need to also use it in = the SET document before it is published. > Thanks, >=20 > Yaron >=20 > On 15/06/17 22:08, Justin Richer wrote: >> +1 to this as well. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: >>>=20 >>> +1 to what Annabelle said. >>>=20 >>> Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >>>=20 >>> Marius >>>=20 >>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) = > wrote: >>> +1 >>>=20 >>> Phil >>>=20 >>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >>>=20 >>>> Mike, >>>>=20 >>>> =20 >>>> Your explanation for why this is a non-problem is dependent upon = side effects of elements of OpenID Connect that were not designed to = solve this issue. As a result, I see several issues with it: >>>>=20 >>>> 1. The caller of the Token Endpoint is the only party that = can be certain that a nonce-less ID Token is really an ID Token. Any = party that the caller passes the ID Token off to has no way to verify = its provenance. >>>>=20 >>>> 2. Any future ID Token distribution method needs to solve = this problem again. >>>>=20 >>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >>>>=20 >>>> 4. This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem. >>>>=20 >>>> =20 >>>> We know from experience that naming collisions and replay attacks = are both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. >>>>=20 >>>> =20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> Identity Services >>>>=20 >>>> =20 >>>> =20 >>>> From: Id-event > on behalf of Mike Jones = > >>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>> To: Marius Scurtescu > >>>> Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>>>=20 >>>> =20 >>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematur= e pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >>>>=20 >>>> =20 >>>> Mandatory solutions are being proposed in this thread to problems = that there=E2=80=99s no evidence that we actually even have. It=E2=80=99s= already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >>>>=20 >>>> =20 >>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the = use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type = claim, would make previously simple things unnecessarily complex. Yes, = then the result is then different than a normal JWT but a consequence of = this is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. >>>>=20 >>>> =20 >>>> -- Mike >>>>=20 >>>> =20 >>>> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle >>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>> To: Marius Scurtescu >; Henk Birkholz = > >>>> Cc: ID Events Mailing List > >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>>>=20 >>>> =20 >>>> Echoing Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D? >>>>=20 >>>> =20 >>>> To your first question, I think a better analogy would be the X.509 = Key Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context. >>>>=20 >>>> =20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> Identity Services >>>>=20 >>>> =20 >>>> =20 >>>> From: Id-event > on behalf of Marius Scurtescu = > >>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>> To: Henk Birkholz > >>>> Cc: ID Events Mailing List > >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>>>=20 >>>> =20 >>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >>>>=20 >>>> And a 2nd question. >>>>=20 >>>> What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"? >>>>=20 >>>> =20 >>>> "aud" (audience) specifies the target client, but not the intended = usage (access token to authorize resource access or SET to communicate a = security event?) >>>>=20 >>>> =20 >>>> "scope" is not used by SET. >>>>=20 >>>> =20 >>>> I don't know what do you mean by "intend" (or intent)? >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>>=20 >>>> Henk >>>>=20 >>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>=20 >>>> Thanks for putting this together! >>>>=20 >>>> I think the assumptions inherent in 3.9 are flawed: >>>>=20 >>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >>>>=20 >>>> =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >>>>=20 >>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >>>>=20 >>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >>>>=20 >>>> --=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> Identity Services >>>>=20 >>>> *From: *Id-event > on behalf of Dick Hardt = > >>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>> *To: *Marius Scurtescu > >>>> *Cc: *Adam Dawes >, = "matake, nov" >, ID Events Mailing = List >, "Phil Hunt (IDM)" = > >>>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>=20 >>>> Agreed. Note that there is still lots of discussion on what should = be in 3.9. >>>>=20 >>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = = >> wrote: >>>>=20 >>>> Thanks for the pointer Dick, very good timing :-) >>>>=20 >>>> The issue is described by "2.7. Cross-JWT Confusion" and the >>>> mitigation is in "3.9. Use Mutually Exclusive Validation Rules = for >>>> Different Kinds of JWTs", specifically "Use different sets of >>>> required claims...", "Use different keys for different kinds of >>>> JWTs." and "Use different issuers for different kinds of = JWTs.". >>>>=20 >>>> I still think that a "type" claim would bring a lot of clarity = and >>>> safety. >>>>=20 >>>>=20 >>>> Marius >>>>=20 >>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt = >>>> >> = wrote: >>>>=20 >>>> Yaron, Mike and I just published an BCP ID for JWT >>>> http://self-issued.info/?p=3D1690 = >>>>=20 >>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes = >>>> >> = wrote: >>>>=20 >>>> I was initially a fan of keeping SETS to be very = similar to >>>> id tokens but I now think this is a better plan. >>>>=20 >>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov = >>>> >> wrote: >>>>=20 >>>> +1 especially for "type" >>>>=20 >>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>> = >>: >>>>=20 >>>> +1 >>>>=20 >>>> Phil >>>>=20 >>>>=20 >>>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >>>> >>>> >> wrote: >>>> > >>>> > There were a couple of proposals on how to >>>> distinguish SETs from Id Tokens and Access = Tokens in >>>> such a way that naive implementations will not >>>> confuse one for the other and open up security >>>> vulnerabilities. >>>> > >>>> > There is also another important requirement: = the >>>> SET issuer in some cases must be different from = the >>>> "sub" issuer. This is the case of an RP sending = SETs >>>> to an IdP. >>>> > >>>> > With these requirements in mind I propose = the >>>> following: >>>> > - both "sub" and "iss" to be defined at the = event >>>> level >>>> > - "iss" at event level and at top SET level = can >>>> be different >>>> > - "iss" and "sub" at event level can be = different >>>> across events in the same SET >>>> > - "sub" should NOT be present at the top SET >>>> level (this solves the disambiguation), please = note >>>> "should" and not "must" >>>> > >>>> > This solution also allows different profiles = that >>>> define event types to define additional claims >>>> related to sub (like email or phone_number) and >>>> since all these claims will be at the event = level >>>> there will be no collisions or ambiguity. >>>> > >>>> > Another proposal (which I supported) was to >>>> define a composite "aud" claim. This is not = solving >>>> the requirement for a distinct SET issuer. = Also, >>>> having the same claim name having different = syntax >>>> in different token types could lead to = confusion. >>>> > >>>> > And yet another proposal was to introduce a = new >>>> claim for JWTs that defines a "type". This is = not >>>> practical in the short term, and it also is not >>>> solving the distinct issuer requirement, but I = think >>>> this is something the JWT group should = seriously >>>> consider. >>>> > >>>> > Thoughts? >>>> > >>>> > Marius >>>>=20 >>>> > = _______________________________________________ >>>> > Id-event mailing list >>>>=20 >>>> > Id-event@ietf.org = > >>>> > >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org = > >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org = > >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>=20 >>>> --=20 >>>> Adam Dawes | Sr. Product Manager |adawes@google.com = >>>> > = |+1 650-214-2410 >>>> > >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org = > >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>=20 >>>> --=20 >>>> Subscribe to the HARDTWARE > mail list to >>>> learn about projects I am working on! >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event = >>>> =20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = =20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_29D70A81-1E2C-41D0-901B-C8E65BA02BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the envelope typ is a media/mime type.  Registering = application/idt+jwt if we register jwt as a structured name sufix. =  

Using the cty = is also possible.   I need to think about what is better but we can = agree on a convention.

Not everything is going to be a set = token like not every JWS is a JWT.

If we are going to define processing = rules to stop collisions and confusion around JWT for different = purposes, we should just start using the typ parameter based on the = existing spec.

In general content sniffing if there is more than one option = eventually gets you into trouble.

I am not convinced that forcing there = to be no sub at the top level is a good idea.  

It is not the way we = should differentiate between SET and id_tokens.

If sub is not allowed at = the top level people will do non SET JWT for things where the subject is = scoped to the iss of the token.

I think defining sub to be part of the = event for cases where the sub is scoped differently from the issuer of = the token is fine, but should not be required for all event = types.

I think = we should solve the confusion issue separately from the sub = issue.

Sorry I = am at CIS so trying to catch up on lists.

John B.

On = Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

=20 =20

So = to summarize what I'm seeing on this thread:

Everybody = agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET = spec.

Almost everybody agrees on a long-term "usage" = claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, = if we do add a "usage" claim, we need to also use it in the SET document before it is published.

Thanks,

    = Yaron


On 15/06/17 22:08, Justin Richer = wrote:
+1 to this as well.

 =E2=80=94 Justin

On Jun 15, 2017, at 1:09 PM, Marius = Scurtescu <mscurtescu@google.com> wrote:

+1 to what Annabelle said.

Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this = case.

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1

Phil

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Mike,

 

Your = explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.       The caller of = the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.       Any future ID = Token distribution method needs to solve this problem again.

3.      No other = profile of JWT can ever use the "nonce=E2=80=9D = claim.

4.      This is only a = solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

 

We know from = experience that naming collisions and replay attacks are both things that happen. What=E2=80=99s being proposed is a = simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A =E2=80=9Cusage-aware=E2= =80=9D JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.

 

-- 

Annabelle Richard Backman

Identity Services

 
 

From: Id-event = <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

You=E2=80=99ve = heard of =E2=80=9Cpremature optimization=E2=80=9D.  I=E2=80=99= d characterize the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D= =E2=80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do = so.

 

Mandatory = solutions are being proposed in this thread to problems that there=E2=80=99s no = evidence that we actually even have.  = It=E2=80=99s already been established that it=E2=80= =99s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our = part.

 

The proposed = =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result = is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT = parser.  The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple = is the key to adoption.  Standards = are only useful if they are actually used.

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of = Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

Echoing = Marius=E2=80=99s question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?

 

To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.

 

-- 

Annabelle Richard Backman

Identity Services

 
 

From: Id-event = <id-event-bounces@ietf.org> on behalf of Marius Scurtescu = <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk = Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?

 

"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)

 

"scope" is not used by SET.

 

I don't know what do you mean by "intend" (or intent)?

 
 



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this = together!

I think the assumptions inherent in 3.9 are = flawed:

=C2=B7We can=E2=80=99t = guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a =E2=80=9Cfail = on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t= be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to = expect implementers to adhere to the =E2=80=9Cdifferent keys = for different kinds of JWTs=E2=80=9D= rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2= =80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D= or =E2=80=9Cusage=E2=80=9D claim/header parameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
= *To: *Marius Scurtescu = <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List = <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:mscurtescu@google.com>>= wrote:

    Thanks for the = pointer Dick, very good timing = :-)

    The issue is = described by "2.7. Cross-JWT Confusion" and the
    mitigation is = in "3.9. Use Mutually Exclusive Validation Rules for
    Different = Kinds of JWTs", specifically "Use different sets of
    required = claims...", "Use different keys for different kinds of
    JWTs." and = "Use different issuers for different kinds of = JWTs.".

    I still think = that a "type" claim would bring a lot of clarity and
    safety.


    Marius

    On Thu, Jun 8, = 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        = Yaron, Mike and I just published an BCP ID for JWT
        = http://self-issued.info/?p=3D1690

        = On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
        = <mailto:adawes@google.com>> wrote:

        =     I was initially a fan of keeping SETS to be very similar to
=         =     id tokens but I now think this is a better plan.

        =     On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
        =     <mailto:nov@matake.jp>> wrote:

        =         +1 especially for "type"

        =         2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
        =         <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>>:

        =             +1

        =             Phil


        =              > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
        =             <mscurtescu@google.com

            =         <mailto:mscurtescu@google.com>>= wrote:
      =                >
      =                > There were a couple of proposals on how to
      =               distinguish SETs from Id Tokens and Access Tokens in
      =               such a way that naive implementations will = not
      =               confuse one for the other and open up security
      =               vulnerabilities.
      =                >
      =                > There is also another important requirement: the
      =               SET issuer in some cases must be different from the
      =               "sub" issuer. This is the case of an RP sending SETs
      =               to an IdP.
      =                >
      =                > With these requirements in mind I propose the
=       =               following:
      =                > - both "sub" = and "iss" to be defined at the event
      =               level
      =                > - "iss" at = event level and at top SET level can
      =               be different
      =                > - "iss" and = "sub" at event level can be different
      =               across events in the same SET
      =                > - "sub" = should NOT be present at the top SET
      =               level (this solves the disambiguation), please note
      =               "should" and not = "must"
      =                >
      =                > This solution = also allows different profiles that
      =               define event types to define additional = claims
      =               related to sub (like email or phone_number) and
      =               since all these claims will be at the event level
      =               there will be no collisions or = ambiguity.
      =                >
      =                > Another = proposal (which I supported) was to
      =               define a composite "aud" claim. This is not solving
      =               the requirement for a distinct  SET = issuer. Also,
      =               having the same claim name having different syntax
      =               in different token types could lead to = confusion.
      =                >
      =                > And yet = another proposal was to introduce a new
      =               claim for JWTs that defines a "type". This is not
      =               practical in the short term, and it also is = not
      =               solving the distinct issuer requirement, but I think
      =               this is something the JWT group should = seriously
      =               consider.
      =                >
      =                > Thoughts?
      =                >
      =                > Marius

      =                > = _______________________________________________
      =                > Id-event = mailing list

          =            > Id-event@ietf.org <mailto:Id-event@ietf.org>
        =              >
        =             https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

        =             = _______________________________________________
        =             Id-event mailing list
        =             Id-event@ietf.org <mailto:Id-event@ietf.org>
        =             https://www.ietf.org/mailman/listinfo/id-event

        =         = _______________________________________________
        =         Id-event mailing list
        =         Id-event@ietf.org <mailto:Id-event@ietf.org>
        =         https://www.ietf.org/mailman/listinfo/id-event

        =     --
        =     Adam Dawes | Sr. Product Manager |adawes@google.com
        =     <mailto:adawes@google.com> |+1 650-214-2410
        =     <tel:(650)%20214-2410>

        =     = _______________________________________________
        =     Id-event mailing list
        =     Id-event@ietf.org <mailto:Id-event@ietf.org>
        =     https://www.ietf.org/mailman/listinfo/id-event

        = --
        = Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        = learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 
_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.o= rg/mailman/listinfo/id-event



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/id-event

_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_29D70A81-1E2C-41D0-901B-C8E65BA02BAC-- --001a11352a32a7f3bb05527e5d11 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIFGNeFvm/ECVzN/85BgY4bTs9Z9q JlxX/oCh54lKuoQGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYyMTIwMzkzNFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBvM4q6mf2tExs9qFuXCFJ6DB28IAnhX39zkBXPvX9gGeNR HZR0jeWo5hd2a69f3LET6O7qBlnD1Bb+44s0ssBsuAmyO6EYpJ2s6KvJyCQP7dvHIr/aWHPx3Qpp Cd34ZpSdeELe3tqYylyQMOvYIexj+84BsYazcSMKESmdX0Aq9lKX8NBn1MxY59QfUuVLmqTIQ0ul p8R7Btw0OuqsKHm7T2wGGkHzVvpETCuLZ3b+vKxTYuelbBmlIsGQmGSUlPfR74ua8GPOaiILxAj6 hrHy6FeFvAyZ/xKtJWdrPr5LKY7iARx7s9EnDpTfbkKZSpxqLKmYawWtMH/UgZ2rCsNX --001a11352a32a7f3bb05527e5d11-- From nobody Wed Jun 21 13:54:22 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BE81274D2 for ; Wed, 21 Jun 2017 13:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.831 X-Spam-Level: X-Spam-Status: No, score=-9.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hiLOLzhg2No for ; Wed, 21 Jun 2017 13:54:16 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8600D126CBF for ; Wed, 21 Jun 2017 13:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1498078456; x=1529614456; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kgXBf5lSZ7AbsSBuI0e1DcL1hzUDBqpe9AtKYbpWCHo=; b=fjvGL0sUu5RSoPHa/67P352aC9t8GFIg0ckdA6JE1yopYv07cebcjTcd J9XsvnHaIWdZsXCwI2/wmPYIFyMv7vZlUtJ1VdgNUFOpjmIoVWsHz2+4Q YTYBS7vEfpExwMe3M9LWuwSvXSekUet9tdplyUwvahIGBetdPWlrDWa02 Q=; X-IronPort-AV: E=Sophos;i="5.39,370,1493683200"; d="scan'208,217";a="675868378" Received: from sea19-co-svc-lb5-vlan3.sea.amazon.com (HELO email-inbound-relay-71007.iad55.amazon.com) ([10.47.22.166]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 20:54:13 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-71007.iad55.amazon.com (8.14.7/8.14.7) with ESMTP id v5LKs5BA024890 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2017 20:54:10 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Jun 2017 20:54:09 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Jun 2017 20:54:09 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Wed, 21 Jun 2017 20:54:09 +0000 From: "Richard Backman, Annabelle" To: John Bradley , Yaron Sheffer CC: Justin Richer , Marius Scurtescu , Phil Hunt , Michael Jones , ID Events Mailing List , Henk Birkholz Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwAgAEftACAAJUjgP//9x6AgAG/8QD//9AlgAAO8LsAACLOTQAABCSqAABn9XkAAMj4pQD//468gA== Date: Wed, 21 Jun 2017 20:54:09 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> In-Reply-To: <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.124] Content-Type: multipart/alternative; boundary="_000_B93EF6E64D6F4A18A6EE9EF28FC21C1Bamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:54:21 -0000 --_000_B93EF6E64D6F4A18A6EE9EF28FC21C1Bamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEpvaG4gdGhhdCB0aGUgSldUIHR5cGUgY29uZnVzaW9uIHByb2JsZW0gYW5k IHRoZSBTRVQgc3ViIHByb2JsZW0gY2FuIGFuZCBzaG91bGQgYmUgZGlzY3Vzc2VkIHNlcGFyYXRl bHkuIFRoZSBzZWNldmVudHMgV0cgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCBzZXR0aW5nIHRv IGRpc2N1c3MgdGhlIGZvcm1lci4NCg0KTXkgY29uY2VybiB3aXRoIHRoZSBzdWIgY2xhaW0gaXMg dGhhdCB0d28gcHJvZmlsZXMgbWF5IGRpY3RhdGUgY29uZmxpY3Rpbmcgc2VtYW50aWNzIChlLmcu IFByb2ZpbGUgQSBzYXlzIGl04oCZcyBhIHBob25lIG51bWJlciwgUHJvZmlsZSBCIHNheXMgaXTi gJlzIGFuIGVtYWlsIGFkZHJlc3MpLiBJZiB0aGVzZSBwcm9maWxlcyBkb27igJl0IHByb3ZpZGUg YW4gYWx0ZXJuYXRlIHdheSB0byBkZWNsYXJlIHN1YmplY3Qgb2YgdGhlaXIgZXZlbnRzLCB0aGVu IHRoZXkgY2Fubm90IGJlIHByZXNlbnQgd2l0aGluIHRoZSBzYW1lIHRva2VuLiBUaGlzIGluY29t cGF0aWJpbGl0eSB0cmFwIHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgY291bGQgYmUgZWFzaWx5 IG1pc3NlZCBieSBncm91cHMgcHJvZmlsaW5nIFNFVC4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyBhdCAxOjM5IFBN DQpUbzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPg0KQ2M6IEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29v Z2xlLmNvbT4sIEFubmFiZWxsZSBSaWNoYXJkIDxyaWNoYW5uYUBhbWF6b24uY29tPiwgUGhpbCBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4sIE1pY2hhZWwgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3Jn PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4NClN1Ympl Y3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9u IGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCkluIHRoZSBlbnZlbG9wZSB0eXAgaXMgYSBtZWRp YS9taW1lIHR5cGUuICBSZWdpc3RlcmluZyBhcHBsaWNhdGlvbi9pZHQrand0IGlmIHdlIHJlZ2lz dGVyIGp3dCBhcyBhIHN0cnVjdHVyZWQgbmFtZSBzdWZpeC4NCg0KVXNpbmcgdGhlIGN0eSBpcyBh bHNvIHBvc3NpYmxlLiAgIEkgbmVlZCB0byB0aGluayBhYm91dCB3aGF0IGlzIGJldHRlciBidXQg d2UgY2FuIGFncmVlIG9uIGEgY29udmVudGlvbi4NCg0KTm90IGV2ZXJ5dGhpbmcgaXMgZ29pbmcg dG8gYmUgYSBzZXQgdG9rZW4gbGlrZSBub3QgZXZlcnkgSldTIGlzIGEgSldULg0KDQpJZiB3ZSBh cmUgZ29pbmcgdG8gZGVmaW5lIHByb2Nlc3NpbmcgcnVsZXMgdG8gc3RvcCBjb2xsaXNpb25zIGFu ZCBjb25mdXNpb24gYXJvdW5kIEpXVCBmb3IgZGlmZmVyZW50IHB1cnBvc2VzLCB3ZSBzaG91bGQg anVzdCBzdGFydCB1c2luZyB0aGUgdHlwIHBhcmFtZXRlciBiYXNlZCBvbiB0aGUgZXhpc3Rpbmcg c3BlYy4NCg0KSW4gZ2VuZXJhbCBjb250ZW50IHNuaWZmaW5nIGlmIHRoZXJlIGlzIG1vcmUgdGhh biBvbmUgb3B0aW9uIGV2ZW50dWFsbHkgZ2V0cyB5b3UgaW50byB0cm91YmxlLg0KDQpJIGFtIG5v dCBjb252aW5jZWQgdGhhdCBmb3JjaW5nIHRoZXJlIHRvIGJlIG5vIHN1YiBhdCB0aGUgdG9wIGxl dmVsIGlzIGEgZ29vZCBpZGVhLg0KDQpJdCBpcyBub3QgdGhlIHdheSB3ZSBzaG91bGQgZGlmZmVy ZW50aWF0ZSBiZXR3ZWVuIFNFVCBhbmQgaWRfdG9rZW5zLg0KDQpJZiBzdWIgaXMgbm90IGFsbG93 ZWQgYXQgdGhlIHRvcCBsZXZlbCBwZW9wbGUgd2lsbCBkbyBub24gU0VUIEpXVCBmb3IgdGhpbmdz IHdoZXJlIHRoZSBzdWJqZWN0IGlzIHNjb3BlZCB0byB0aGUgaXNzIG9mIHRoZSB0b2tlbi4NCg0K SSB0aGluayBkZWZpbmluZyBzdWIgdG8gYmUgcGFydCBvZiB0aGUgZXZlbnQgZm9yIGNhc2VzIHdo ZXJlIHRoZSBzdWIgaXMgc2NvcGVkIGRpZmZlcmVudGx5IGZyb20gdGhlIGlzc3VlciBvZiB0aGUg dG9rZW4gaXMgZmluZSwgYnV0IHNob3VsZCBub3QgYmUgcmVxdWlyZWQgZm9yIGFsbCBldmVudCB0 eXBlcy4NCg0KSSB0aGluayB3ZSBzaG91bGQgc29sdmUgdGhlIGNvbmZ1c2lvbiBpc3N1ZSBzZXBh cmF0ZWx5IGZyb20gdGhlIHN1YiBpc3N1ZS4NCg0KU29ycnkgSSBhbSBhdCBDSVMgc28gdHJ5aW5n IHRvIGNhdGNoIHVwIG9uIGxpc3RzLg0KDQpKb2huIEIuDQoNCk9uIEp1biAxNywgMjAxNywgYXQg Mzo0NSBQTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJv bmYuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KU28gdG8gc3VtbWFyaXplIHdoYXQgSSdtIHNl ZWluZyBvbiB0aGlzIHRocmVhZDoNCkV2ZXJ5Ym9keSBhZ3JlZXMgd2l0aCBNYXJpdXMncyBzaG9y dC10ZXJtIHNvbHV0aW9uLCBzcGVjaWZpYyBydWxlcyBmb3IgInN1YiIgYW5kICJpc3MiIHRoYXQg Y2FuIGJlIGRlZmluZWQgaW4gdGhlIFNFVCBzcGVjLg0KQWxtb3N0IGV2ZXJ5Ym9keSBhZ3JlZXMg b24gYSBsb25nLXRlcm0gInVzYWdlIiBjbGFpbSAoInR5cGUiIGlzIHRha2VuKSB0aGF0IHNob3Vs ZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJDUC4NCkRpZCBJIG1pc3Mg YW55dGhpbmc/DQpCeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAidXNhZ2UiIGNsYWltLCB3ZSBu ZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1lbnQgYmVmb3JlIGl0IGlzIHB1Ymxp c2hlZC4NClRoYW5rcywNCiAgICBZYXJvbg0KDQpPbiAxNS8wNi8xNyAyMjowOCwgSnVzdGluIFJp Y2hlciB3cm90ZToNCisxIHRvIHRoaXMgYXMgd2VsbC4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSnVu IDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2ds ZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQorMSB0byB3aGF0 IEFubmFiZWxsZSBzYWlkLg0KDQpBbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIg cmVxdWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzK3N1 YiBwYWlyIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS4NCg0KTWFyaXVz DQoNCk9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQor MQ0KDQpQaGlsDQoNCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5j b20+PiB3cm90ZToNCk1pa2UsDQoNCllvdXIgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGlzIGlzIGEg bm9uLXByb2JsZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3RzIG9mIGVsZW1lbnRzIG9m IE9wZW5JRCBDb25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBpc3N1 ZS4gQXMgYSByZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGggaXQ6DQoNCjEuICAgICAg IFRoZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQg Y2FuIGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElE IFRva2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2Zm IHRvIGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLg0KDQoyLiAgICAgICBBbnkg ZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBw cm9ibGVtIGFnYWluLg0KDQozLiAgICAgIE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVy IHVzZSB0aGUgIm5vbmNl4oCdIGNsYWltLg0KDQo0LiAgICAgIFRoaXMgaXMgb25seSBhIHNvbHV0 aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBwcm9maWxlIHRoYXQgY2FyZXMgYWJv dXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMgb3duIHNvbHV0aW9uIHRvIHRoZSBw cm9ibGVtLg0KDQpXZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5hbWluZyBjb2xsaXNpb25z IGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBoYXBwZW4uIFdoYXTigJlz IGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRo ZXNlIHJpc2tzLiBZb3UgYnJvdWdodCB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRp b24gYWN0dWFsbHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24gbGlicmFyaWVzIGZvciBK V1QgcGFyc2luZy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFyeSBjb3VsZCBoYW5kbGUg ZGlzYW1iaWd1YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVhcyB3aXRoIHRoZSBzdGF0 dXMgcXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy4NCg0KLS0NCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQt ZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogV2VkbmVz ZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE0NClRvOiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1 cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpDYzogIlJp Y2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmlj aGFubmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRv a2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpZb3XigJl2ZSBoZWFyZCBv ZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiAgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBw cm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKA kyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBsZXgsIHdp dGhvdXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBkbyBzby4NCg0KTWFuZGF0 b3J5IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhpcyB0aHJlYWQgdG8gcHJvYmxl bXMgdGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBhY3R1YWxseSBldmVuIGhhdmUu ICBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUg Zm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDigJMgc2VlIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cwMDQyOC5o dG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0 MjguaHRtbCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNs ajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWVLTFRRUG1ZclYzVGhm RGJuOTBTQ3M1NVVST1RQaW5fbGdjNlJkcjVYb3cmZT0+LiAgSWYgcGVvcGxlIGhhdmUgZGF0YSBz aG93aW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2Vz cyBUb2tlbnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNw ZWNpZmljcywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0gYXBwcm9wcmlh dGUgZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC4NCg0KVGhlIHByb3Bvc2VkIOKAnHNv bHV0aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0 aGUgbm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2 aW91c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4LiAgWWVzLCB0aGVuIHRo ZSByZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2Vx dWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBi ZSB1c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuICBUaGUgbW9yZSB1bndp ZWxkeSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxvcGVycyBh cmUgdG8ganVzdCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJlcy4gIEtlZXBpbmcgaXQg c2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uICBTdGFuZGFyZHMgYXJlIG9ubHkgdXNlZnVs IGlmIHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGUNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNTozMyBQTQ0KVG86IE1hcml1 cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8 bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KQ2M6IElEIEV2ZW50cyBN YWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNv bmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hvaW5nIE1hcml1c+KAmXMgcXVl c3Rpb246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT8NCg0K VG8geW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJl IHRoZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0 aGF0IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEg cmVjaXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNjZXB0 IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuDQoNCi0tDQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2 ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xl LmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEp1bmUg MTMsIDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNp dC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4N CkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElk L0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KT24gVHVl LCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBz aXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+ IHdyb3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFudGljcyB3b3VsZCAidXNh Z2UiIHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEgImludGVuZCIsICJhdWRp ZW5jZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNwZWNpZmllcyB0aGUgdGFy Z2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tlbiB0byBh dXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNlY3VyaXR5 IGV2ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoNCkkgZG9uJ3Qga25vdyB3 aGF0IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0KDQoNCg0KDQpIZW5rDQoN Ck9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIHdyb3Rl Og0KVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkgdGhpbmsgdGhlIGFzc3Vt cHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dlIGNhbuKAmXQgZ3VhcmFu dGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0dWFsbHkgZXhjbHVzaXZl IHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0ZXJzLCBhbmQgZW5mb3Jj aW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2duaXplZCBjbGFpbeKAnSBh cHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1cmUgc3BlYyBjYW7igJl0 IGJlIG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMuDQoNCsK3SXQgaXMgdW5y ZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZl cmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1h bmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMg YmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVy ZW50IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCcaXNz4oCdIGNsYWltcy4N Cg0KKzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFpbS9oZWFkZXIgcGFyYW1l dGVyLg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoNCklkZW50aXR5IFNlcnZp Y2VzDQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCA8ZGlj ay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCipEYXRlOiAq TW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1hcml1cyBTY3VydGVzY3Ug PG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCipD YzogKkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bT4+LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtlLmpwPj4s IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVu dEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVudF0gc29s dXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1 ZXINCg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNjdXNzaW9u IG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4gMTIsIDIwMTcgYXQgMzox NSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1 cnRlc2N1QGdvb2dsZS5jb20+IDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzpt c2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRoZSBwb2lu dGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUgaXMgZGVzY3Jp YmVkIGJ5ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBtaXRpZ2F0aW9u IGlzIGluICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3IN CiAgICBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNlIGRpZmZlcmVu dCBzZXRzIG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJlbnQga2V5cyBm b3IgZGlmZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZlcmVudCBpc3N1 ZXJzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGlsbCB0aGluayB0 aGF0IGEgInR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kDQogICAg c2FmZXR5Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1 OSBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtlIGFuZCBJIGp1 c3QgcHVibGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9zZWxmLWlzc3Vl ZC5pbmZvLz9wPTE2OTA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHAtM0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZkPUR3TUdhUSZjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0Rm dC0wMFlfM3pSb2FpMTE1YyZzPWE3WHZaNWpUYnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpN Y1VJVVEmZT0+DQoNCiAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0g RGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAg ICAgPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+Pj4g d3JvdGU6DQoNCiAgICAgICAgICAgIEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNF VFMgdG8gYmUgdmVyeSBzaW1pbGFyIHRvDQogICAgICAgICAgICBpZCB0b2tlbnMgYnV0IEkgbm93 IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi4NCg0KICAgICAgICAgICAgT24gVGh1LCBKdW4g OCwgMjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZA bWF0YWtlLmpwPg0KICAgICAgICAgICAgPG1haWx0bzpub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZA bWF0YWtlLmpwPj4+IHdyb3RlOg0KDQogICAgICAgICAgICAgICAgKzEgZXNwZWNpYWxseSBmb3Ig InR5cGUiDQoNCiAgICAgICAgICAgICAgICAyMDE3LTA2LTA5IDEwOjMyIEdNVCswOTowMCBQaGls IEh1bnQgKElETSkNCiAgICAgICAgICAgICAgICA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPiA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+PjoNCg0KICAgICAgICAgICAgICAgICAgICArMQ0KDQog ICAgICAgICAgICAgICAgICAgIFBoaWwNCg0KDQogICAgICAgICAgICAgICAgICAgICA+IE9uIEp1 biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAgICAgICAgICAg ICAgIDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4N CiAgICAgICAgICAgICAgICAgICAgPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRv Om1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+PiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgID4N CiAgICAgICAgICAgICAgICAgICAgID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMg b24gaG93IHRvDQogICAgICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBU b2tlbnMgYW5kIEFjY2VzcyBUb2tlbnMgaW4NCiAgICAgICAgICAgICAgICAgICAgc3VjaCBhIHdh eSB0aGF0IG5haXZlIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAgICAgICAgICAg ICBjb25mdXNlIG9uZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5DQogICAgICAg ICAgICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAg ICAgICAgICAgICAgICAgICAgID4gVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1 aXJlbWVudDogdGhlDQogICAgICAgICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNl cyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAic3ViIiBp c3N1ZXIuIFRoaXMgaXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQogICAgICAgICAg ICAgICAgICAgIHRvIGFuIElkUC4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAg ICAgICAgICAgID4gV2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhl DQogICAgICAgICAgICAgICAgICAgIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgID4g LSBib3RoICJzdWIiIGFuZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudA0KICAgICAg ICAgICAgICAgICAgICBsZXZlbA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGF0IGV2 ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbg0KICAgICAgICAgICAgICAgICAgICBi ZSBkaWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQgInN1YiIgYXQg ZXZlbnQgbGV2ZWwgY2FuIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICBhY3Jvc3Mg ZXZlbnRzIGluIHRoZSBzYW1lIFNFVA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJzdWIiIHNo b3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAgICAgICAgICBs ZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUNCiAgICAg ICAgICAgICAgICAgICAgInNob3VsZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAgICAgICAgICAg ICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBk aWZmZXJlbnQgcHJvZmlsZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgZXZlbnQg dHlwZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAgICAgICAgIHJl bGF0ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kDQogICAgICAgICAg ICAgICAgICAgIHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2 ZWwNCiAgICAgICAgICAgICAgICAgICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFt YmlndWl0eS4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4g QW5vdGhlciBwcm9wb3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAgICAgICAgICAg ICAgICAgICBkZWZpbmUgYSBjb21wb3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZp bmcNCiAgICAgICAgICAgICAgICAgICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0ICBT RVQgaXNzdWVyLiBBbHNvLA0KICAgICAgICAgICAgICAgICAgICBoYXZpbmcgdGhlIHNhbWUgY2xh aW0gbmFtZSBoYXZpbmcgZGlmZmVyZW50IHN5bnRheA0KICAgICAgICAgICAgICAgICAgICBpbiBk aWZmZXJlbnQgdG9rZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uDQogICAgICAgICAg ICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5vdGhlciBwcm9w b3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3DQogICAgICAgICAgICAgICAgICAgIGNsYWltIGZv ciBKV1RzIHRoYXQgZGVmaW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAgICAgICAgICAg ICAgICAgcHJhY3RpY2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3QNCiAg ICAgICAgICAgICAgICAgICAgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50 LCBidXQgSSB0aGluaw0KICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0aGluZyB0aGUg SldUIGdyb3VwIHNob3VsZCBzZXJpb3VzbHkNCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIu DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRob3VnaHRz Pw0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBNYXJpdXMN Cg0KICAgICAgICAgICAgICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudCBtYWlsaW5n IGxpc3QNCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAg IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2 bWlSaUhxV2dmeHFtZyZzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4 V0kmZT0NCg0KICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgICAgICBJZC1ldmVudCBtYWlsaW5n IGxpc3QNCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZy PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQ S0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdM RDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAgICAgICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJE ZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklU WDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQogICAgICAgICAgICAtLQ0KICAgICAg ICAgICAgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfGFkYXdlc0Bnb29nbGUuY29t PG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgIDxtYWlsdG86YWRhd2VzQGdv b2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4gfCsxIDY1MC0yMTQtMjQxMDx0ZWw6 JTJCMSUyMDY1MC0yMTQtMjQxMD4NCiAgICAgICAgICAgIDx0ZWw6KDY1MCklMjAyMTQtMjQxMDx0 ZWw6JTI4NjUwJTI5JTIwMjE0LTI0MTA+Pg0KDQogICAgICAgICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFp bGluZyBsaXN0DQogICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPj4NCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29N VTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAtLQ0KICAgICAgICBTdWJzY3JpYmUgdG8gdGhlIEhB UkRUV0FSRSA8aHR0cDovL2hhcmR0d2FyZS5jb20vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0Rm dC0wMFlfM3pSb2FpMTE1YyZzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlC ZXJWODAmZT0+PiBtYWlsIGxpc3QgdG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBh bSB3b3JraW5nIG9uIQ0KDQoNCg0KLS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0 dHA6Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4g bWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJv YWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2 ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6 Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9 Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZY Q3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01V N1RtR01TV1dzJmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCg0KSWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQNCg0K --_000_B93EF6E64D6F4A18A6EE9EF28FC21C1Bamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <57D442E08B93C0458EE36687189A8527@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KcC5tOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJh Z3JhcGgsIGxpLm05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCwgZGl2Lm05MDk0 MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzkwOTQw ODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SSBhZ3JlZSB3aXRoIEpvaG4gdGhhdCB0aGUgSldUIHR5cGUgY29uZnVzaW9uIHByb2JsZW0gYW5k IHRoZSBTRVQgc3ViIHByb2JsZW0gY2FuIGFuZCBzaG91bGQgYmUgZGlzY3Vzc2VkIHNlcGFyYXRl bHkuIFRoZSBzZWNldmVudHMgV0cgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCBzZXR0aW5nIHRv DQogZGlzY3VzcyB0aGUgZm9ybWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NeSBjb25jZXJuIHdpdGggdGhl IHN1YiBjbGFpbSBpcyB0aGF0IHR3byBwcm9maWxlcyBtYXkgZGljdGF0ZSBjb25mbGljdGluZyBz ZW1hbnRpY3MgKGUuZy4gUHJvZmlsZSBBIHNheXMgaXTigJlzIGEgcGhvbmUgbnVtYmVyLCBQcm9m aWxlIEIgc2F5cyBpdOKAmXMgYW4gZW1haWwgYWRkcmVzcykuIElmIHRoZXNlDQogcHJvZmlsZXMg ZG9u4oCZdCBwcm92aWRlIGFuIGFsdGVybmF0ZSB3YXkgdG8gZGVjbGFyZSBzdWJqZWN0IG9mIHRo ZWlyIGV2ZW50cywgdGhlbiB0aGV5IGNhbm5vdCBiZSBwcmVzZW50IHdpdGhpbiB0aGUgc2FtZSB0 b2tlbi4gVGhpcyBpbmNvbXBhdGliaWxpdHkgdHJhcCBzZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0 IGNvdWxkIGJlIGVhc2lseSBtaXNzZWQgYnkgZ3JvdXBzIHByb2ZpbGluZyBTRVQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklkZW50aXR5 IFNlcnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2huIEJyYWRsZXkgJmx0O3ZlN2p0 YkB2ZTdqdGIuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEp1bmUgMjEsIDIw MTcgYXQgMTozOSBQTTxicj4NCjxiPlRvOiA8L2I+WWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmll dGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hl ckBtaXQuZWR1Jmd0OywgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29t Jmd0OywgQW5uYWJlbGxlIFJpY2hhcmQgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7LCBQaGls IEh1bnQgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OywgTWljaGFlbCBKb25lcyAmbHQ7TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OywgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7LCBIZW5rIEJpcmtob2x6DQogJmx0O2hlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGUmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRd IHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQg aXNzdWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHRoZSBlbnZlbG9wZSB0eXAgaXMgYSBtZWRpYS9taW1lIHR5cGUuICZuYnNwO1JlZ2lz dGVyaW5nIGFwcGxpY2F0aW9uL2lkdCYjNDM7and0IGlmIHdlIHJlZ2lzdGVyIGp3dCBhcyBhIHN0 cnVjdHVyZWQgbmFtZSBzdWZpeC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Vc2luZyB0aGUgY3R5IGlzIGFsc28gcG9zc2libGUuICZuYnNwOyBJ IG5lZWQgdG8gdGhpbmsgYWJvdXQgd2hhdCBpcyBiZXR0ZXIgYnV0IHdlIGNhbiBhZ3JlZSBvbiBh IGNvbnZlbnRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ob3QgZXZlcnl0aGluZyBpcyBnb2luZyB0byBiZSBhIHNldCB0b2tl biBsaWtlIG5vdCBldmVyeSBKV1MgaXMgYSBKV1QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGFyZSBnb2luZyB0byBkZWZpbmUgcHJv Y2Vzc2luZyBydWxlcyB0byBzdG9wIGNvbGxpc2lvbnMgYW5kIGNvbmZ1c2lvbiBhcm91bmQgSldU IGZvciBkaWZmZXJlbnQgcHVycG9zZXMsIHdlIHNob3VsZCBqdXN0IHN0YXJ0IHVzaW5nIHRoZSB0 eXAgcGFyYW1ldGVyIGJhc2VkIG9uIHRoZSBleGlzdGluZyBzcGVjLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBnZW5lcmFsIGNvbnRlbnQg c25pZmZpbmcgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBvcHRpb24gZXZlbnR1YWxseSBnZXRz IHlvdSBpbnRvIHRyb3VibGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IGZvcmNpbmcgdGhlcmUgdG8g YmUgbm8gc3ViIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYSBnb29kIGlkZWEuICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3Qg dGhlIHdheSB3ZSBzaG91bGQgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIFNFVCBhbmQgaWRfdG9rZW5z LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc3ViIGlz IG5vdCBhbGxvd2VkIGF0IHRoZSB0b3AgbGV2ZWwgcGVvcGxlIHdpbGwgZG8gbm9uIFNFVCBKV1Qg Zm9yIHRoaW5ncyB3aGVyZSB0aGUgc3ViamVjdCBpcyBzY29wZWQgdG8gdGhlIGlzcyBvZiB0aGUg dG9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgZGVmaW5pbmcgc3ViIHRvIGJlIHBhcnQgb2YgdGhlIGV2ZW50IGZvciBjYXNl cyB3aGVyZSB0aGUgc3ViIGlzIHNjb3BlZCBkaWZmZXJlbnRseSBmcm9tIHRoZSBpc3N1ZXIgb2Yg dGhlIHRva2VuIGlzIGZpbmUsIGJ1dCBzaG91bGQgbm90IGJlIHJlcXVpcmVkIGZvciBhbGwgZXZl bnQgdHlwZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdGhpbmsgd2Ugc2hvdWxkIHNvbHZlIHRoZSBjb25mdXNpb24gaXNzdWUgc2VwYXJh dGVseSBmcm9tIHRoZSBzdWIgaXNzdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5IEkgYW0gYXQgQ0lTIHNvIHRyeWluZyB0byBjYXRj aCB1cCBvbiBsaXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDE3LCAyMDE3LCBhdCAzOjQ1IFBNLCBZYXJvbiBTaGVm ZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj55YXJvbmYuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+U28gdG8gc3VtbWFyaXplIHdoYXQgSSdtIHNlZWluZyBvbiB0aGlz IHRocmVhZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXZlcnlib2R5 IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmljIHJ1bGVz IGZvciAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0aGF0IGNhbiBiZSBkZWZp bmVkIGluIHRoZSBTRVQgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QWxtb3N0IGV2ZXJ5Ym9keSBhZ3JlZXMgb24gYSBsb25nLXRlcm0gJnF1b3Q7dXNhZ2UmcXVv dDsgY2xhaW0gKCZxdW90O3R5cGUmcXVvdDsgaXMgdGFrZW4pIHRoYXQgc2hvdWxkIGJlIGRlZmlu ZWQgZWxzZXdoZXJlLCBlLmcuIGluIHRoZSBKV1QgQkNQLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5EaWQgSSBtaXNzIGFueXRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5CeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAmcXVvdDt1c2Fn ZSZxdW90OyBjbGFpbSwgd2UgbmVlZCB0byBhbHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50 IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAx NS8wNi8xNyAyMjowOCwgSnVzdGluIFJpY2hlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgdG8gdGhpcyBhcyB3ZWxsLiA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEp1biAxNSwgMjAxNywgYXQgMTowOSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOzEgdG8gd2hhdCBBbm5hYmVsbGUgc2FpZC4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIg cmVxdWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzJiM0 MztzdWIgcGFpciBhdCB0aGUgdG9wIGxldmVsIGlzIGJyb2tlbiBpbiB0aGlzIGNhc2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEp1biAxNCwgMjAxNyBhdCA1OjMzIFBNLCBQaGlsIEh1bnQgKElETSkg Jmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWls U2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBsZU1haWxTaWduYXR1cmUi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFyZCBCYWNr bWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPk1pa2UsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91 ciBleHBsYW5hdGlvbiBmb3Igd2h5IHRoaXMgaXMgYSBub24tcHJvYmxlbSBpcyBkZXBlbmRlbnQg dXBvbiBzaWRlIGVmZmVjdHMgb2YgZWxlbWVudHMgb2YgT3BlbklEIENvbm5lY3QgdGhhdA0KIHdl cmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFzIGEgcmVzdWx0LCBJIHNlZSBz ZXZlcmFsIGlzc3VlcyB3aXRoIGl0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt OTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MS48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY2FsbGVyIG9mIHRo ZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBjZXJ0YWluIHRo YXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tlbi4gQW55IHBhcnR5 IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBoYXMgbm8gd2F5IHRv DQogdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Mi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbnkgZnV0dXJlIElE IFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFn YWluLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTA5NDA4OTIzOTY2ODU3MDMx Mm1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Tm8gb3RoZXIgcHJvZmlsZSBvZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAmcXVvdDtub25jZeKAnSBj bGFpbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTkwOTQwODkyMzk2Njg1NzAz MTJtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoaXMgaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBw cm9maWxlIHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMg b3duIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPldlIGtub3cgZnJvbSBleHBlcmllbmNlIHRoYXQgbmFtaW5nIGNvbGxpc2lvbnMgYW5kIHJl cGxheSBhdHRhY2tzIGFyZSBib3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4gV2hhdOKAmXMgYmVpbmcg cHJvcG9zZWQNCiBpcyBhIHNpbXBsZSwgZGVmZW5zaXZlIG1lYXN1cmUgYWdhaW5zdCB0aGVzZSBy aXNrcy4gWW91IGJyb3VnaHQgdXAgSldUIGxpYnJhcmllczogYSBnZW5lcmFsIHNvbHV0aW9uIGFj dHVhbGx5IG1ha2VzIGl0IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJhcmllcyBmb3IgSldUIHBh cnNpbmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQgaGFuZGxlIGRpc2Ft YmlndWF0aW9uIGZvciBhbnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aA0KIHRoZSBzdGF0dXMg cXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBsb2dpYy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9h PiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYg UE08YnI+DQo8Yj5UbzogPC9iPk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzpt c2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5j b208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVs bGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBJRCBFdmVudHMgTWFpbGluZyBM aXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7LCBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJt YWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBh bmQgZGlzdGluY3QgU0VUIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+WW914oCZ dmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4mbmJzcDsgSeKAmWQgY2hh cmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBl c3NpbWF0aW9u4oCdDQog4oCTIG1ha2luZyB0aGluZ3MgdGhhdCBjYW4gYW5kIHNob3VsZCBiZSBz aW1wbGUgY29tcGxleCwgd2l0aG91dCBkYXRhIHNob3dpbmcgdGhlcmXigJlzIGFueSBuZWVkIHRv IGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJl IGJlaW5nIHByb3Bvc2VkIGluIHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlz IG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZlLiZuYnNwOw0KIEl04oCZcyBh bHJlYWR5IGJlZW4gZXN0YWJsaXNoZWQgdGhhdCBpdOKAmXMgaW1wb3NzaWJsZSBmb3IgYSBTRVQg dG8gYmUgY29uZnVzZWQgZm9yIGFuIElEIFRva2VuIOKAkyBzZWUNCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZhbXA7 ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDtt PVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9ZUtMVFFQ bVlyVjNUaGZEYm45MFNDczU1VVJPVFBpbl9sZ2M2UmRyNVhvdyZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3Vy cmVudC9tc2cwMDQyOC5odG1sPC9hPi4mbmJzcDsgSWYgcGVvcGxlIGhhdmUgZGF0YSBzaG93aW5n IHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2VzcyBUb2tl bnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNwZWNpZmlj cywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0NCiBhcHByb3ByaWF0ZSBl bmdpbmVlcmluZyBjaG9pY2VzIG9uIG91ciBwYXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PlRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPigJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVz ZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1hbCB3YXksIG9yIHJlcXVpcmluZyBhIHR5cGUgY2xh aW0sIHdvdWxkIG1ha2UNCiBwcmV2aW91c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBj b21wbGV4LiZuYnNwOyBZZXMsIHRoZW4gdGhlIHJlc3VsdCBpcyB0aGVuIGRpZmZlcmVudCB0aGFu IGEgbm9ybWFsIEpXVCBidXQgYSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgY3VzdG9tIHBh cnNpbmcgY29kZSB3b3VsZCBoYXZlIHRvIGJlIHVzZWQsIHJhdGhlciB0aGFuIGEgc3RhbmRhcmQg SldUIHBhcnNlci4mbmJzcDsgVGhlIG1vcmUgdW53aWVsZHkgd2UgbWFrZSBpdCB0byB1c2UgU0VU cywNCiB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxvcGVycyBhcmUgdG8ganVzdCBjcmVhdGUgdGhlaXIg b3duIGRhdGEgc3RydWN0dXJlcy4mbmJzcDsgS2VlcGluZyBpdCBzaW1wbGUgaXMgdGhlIGtleSB0 byBhZG9wdGlvbi4mbmJzcDsgU3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0aGV5IGFyZSBh Y3R1YWxseSB1c2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElkLWV2ZW50 IFs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgSnVuZSAxMywgMjAxNyA1OjMzIFBNPGJyPg0KPGI+VG86PC9iPiBNYXJpdXMgU2N1cnRlc2N1 ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs7IEhlbmsgQmlya2hvbHogJmx0OzxhIGhy ZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFu ayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4g Y29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjogY2FuIHlvdSBleHBsYWluIHdoYXQgeW91IG1l YW4gYnkg4oCcaW50ZW5k4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIHlv dXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3b3VsZCBiZSB0aGUg WC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJvcGVydHkNCiB0aGF0 IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVj aXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNjZXB0IGEg SldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B bm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU08YnI+DQo8 Yj5UbzogPC9iPkhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJh dW5ob2Zlci5kZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5JRCBFdmVudHMgTWFpbGluZyBMaXN0 ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p ZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBKdW4g MTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5rLmJpcmto b2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QW5kIGEgMm5kIHF1ZXN0aW9uLjxicj4NCjxicj4NCldoYXQgc2VtYW50aWNz IHdvdWxkICZxdW90O3VzYWdlJnF1b3Q7IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJl ZCB2aWEgJnF1b3Q7aW50ZW5kJnF1b3Q7LCAmcXVvdDthdWRpZW5jZSZxdW90OywgYW5kICZxdW90 O3Njb3BlJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDthdWQmcXVvdDsgKGF1ZGll bmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdldCBjbGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVz YWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0aG9yaXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8g Y29tbXVuaWNhdGUgYSBzZWN1cml0eSBldmVudD8pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7c2NvcGUm cXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9uJ3Qga25vdyB3aGF0 IGRvIHlvdSBtZWFuIGJ5ICZxdW90O2ludGVuZCZxdW90OyAob3IgaW50ZW50KT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YnI+DQo8YnI+DQpIZW5rPGJyPg0KPGJyPg0KT24gMDYvMTMvMjAxNyAwMTowMSBB TSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhPGJyPg0KPGJyPg0K SSB0aGluayB0aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQgaW4gMy45IGFyZSBmbGF3ZWQ6PGJyPg0K PGJyPg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwg aGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFk ZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBh biB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9t IHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0YWtlbiBmb3IgSldUcw0KIGZyb20gYSBj dXJyZW50IHNwZWMuPGJyPg0KPGJyPg0KwrdJdCBpcyB1bnJlYWxpc3RpYyB0byBleHBlY3QgaW1w bGVtZW50ZXJzIHRvIGFkaGVyZSB0byB0aGUg4oCcZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVu dCBraW5kcyBvZiBKV1Rz4oCdIHJ1bGUuIFdoZXRoZXIgbWFuZGF0ZWQgYnkgdGhlIHNwZWMgb3Ig bm90LCBpbXBsZW1lbnRlcnMgd2lsbCBpZ25vcmUgdGhpcyBiZWNhdXNlIG1hbmFnaW5nIG9uZSBr ZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZmZXJlbnQga2V5cy48YnI+DQo8YnI+DQrC t0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBjbGFpbXMuPGJyPg0KPGJyPg0KJiM0 MzsxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRl ci48YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPGJy Pg0KPGJyPg0KSWRlbnRpdHkgU2VydmljZXM8YnI+DQo8YnI+DQoqRnJvbTogKklkLWV2ZW50ICZs dDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBK dW5lIDEyLCAyMDE3IGF0IDM6MTggUE08YnI+DQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8 YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNj dXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQoqQ2M6ICpBZGFtIERhd2VzICZsdDs8YSBo cmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29v Z2xlLmNvbTwvYT4mZ3Q7LCAmcXVvdDttYXRha2UsIG5vdiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5rIj5ub3ZAbWF0YWtlLmpwPC9hPiZndDss IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7 UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0K KlN1YmplY3Q6ICpSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNv bmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcjxicj4NCjxicj4NCkFncmVlZC4gTm90ZSB0 aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB3aGF0IHNob3VsZCBiZSBp biAzLjkuPGJyPg0KPGJyPg0KT24gTW9uLCBKdW4gMTIsIDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVz IFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNj dUBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg VGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2ZXJ5IGdvb2QgdGltaW5nIDotKTxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgVGhlIGlzc3VlIGlzIGRlc2NyaWJlZCBieSAmcXVvdDsyLjcuIENy b3NzLUpXVCBDb25mdXNpb24mcXVvdDsgYW5kIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgbWl0aWdh dGlvbiBpcyBpbiAmcXVvdDszLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBS dWxlcyBmb3I8YnI+DQombmJzcDsgJm5ic3A7IERpZmZlcmVudCBLaW5kcyBvZiBKV1RzJnF1b3Q7 LCBzcGVjaWZpY2FsbHkgJnF1b3Q7VXNlIGRpZmZlcmVudCBzZXRzIG9mPGJyPg0KJm5ic3A7ICZu YnNwOyByZXF1aXJlZCBjbGFpbXMuLi4mcXVvdDssICZxdW90O1VzZSBkaWZmZXJlbnQga2V5cyBm b3IgZGlmZmVyZW50IGtpbmRzIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyBKV1RzLiZxdW90OyBhbmQg JnF1b3Q7VXNlIGRpZmZlcmVudCBpc3N1ZXJzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4m cXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJIHN0aWxsIHRoaW5rIHRoYXQgYSAmcXVv dDt0eXBlJnF1b3Q7IGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kPGJyPg0K Jm5ic3A7ICZuYnNwOyBzYWZldHkuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBNYXJp dXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQ TSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+PGJyPg0KJm5ic3A7ICZuYnNw OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1 Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9fc2VsZi0yRGlzc3VlZC5pbmZvXy0zRnAtM0QxNjkwJmFtcDtkPUR3TUdhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2ht UWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1hN1h2WjVqVGJ0QTJ2amZhSElNYnZF T3BTQkJsQnBkc0RrSVRaTWNVSVVRJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Nl bGYtaXNzdWVkLmluZm8vP3A9MTY5MDwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMgJmx0Ozxh IGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bn b29nbGUuY29tPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdl c0Bnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVw aW5nIFNFVFMgdG8gYmUgdmVyeSBzaW1pbGFyIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaWQgdG9rZW5zIGJ1dCBJIG5vdyB0aGluayB0aGlzIGlzIGEg YmV0dGVyIHBsYW4uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92ICZsdDs8 YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2Uu anA8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5v dkBtYXRha2UuanA8L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOzEgZXNwZWNpYWxs eSBmb3IgJnF1b3Q7dHlwZSZxdW90Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjAxNy0wNi0wOSAxMDozMiBHTVQmIzQz OzA5OjAwIFBoaWwgSHVudCAoSURNKTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsmZ3Q7Ojxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOzE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhpbDxicj4NCjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJp dXMgU2N1cnRlc2N1PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9h PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyZndDsgd3Jv dGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBUaGVyZSB3ZXJlIGEgY291cGxlIG9mIHByb3Bvc2FscyBvbiBob3cgdG88YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZGlzdGluZ3Vpc2ggU0VUcyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2Vu cyBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRp b25zIHdpbGwgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIg YW5kIG9wZW4gdXAgc2VjdXJpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdnVsbmVyYWJpbGl0aWVzLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg VGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBmcm9t IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzdWImcXVvdDsgaXNzdWVyLiBUaGlzIGlzIHRo ZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcgU0VUczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBhbiBJZFAu PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGU8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZm9sbG93aW5nOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gYm90aCAm cXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0byBiZSBkZWZpbmVkIGF0IHRoZSBl dmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 IC0gJnF1b3Q7aXNzJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNh bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyAtICZxdW90O2lzcyZxdW90OyBhbmQgJnF1b3Q7c3ViJnF1b3Q7IGF0IGV2ZW50IGxldmVs IGNhbiBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWNyb3NzIGV2ZW50cyBpbiB0aGUg c2FtZSBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O3N1YiZxdW90OyBz aG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2 ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFzZSBub3RlPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZxdW90O3Nob3VsZCZxdW90OyBhbmQgbm90ICZxdW90O211c3QmcXVvdDs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRo aXMgc29sdXRpb24gYWxzbyBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZGVmaW5lIGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltczxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1i ZXIpIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUg YXQgdGhlIGV2ZW50IGxldmVsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJlIHdpbGwgYmUgbm8gY29s bGlzaW9ucyBvciBhbWJpZ3VpdHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRl ZCkgd2FzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlZmluZSBhIGNvbXBvc2l0ZSAmcXVvdDthdWQm cXVvdDsgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHJl cXVpcmVtZW50IGZvciBhIGRpc3RpbmN0Jm5ic3A7IFNFVCBpc3N1ZXIuIEFsc28sPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGhhdmluZyB0aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3lu dGF4PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFk IHRvIGNvbmZ1c2lvbi48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNl IGEgbmV3PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBhICZx dW90O3R5cGUmcXVvdDsuIFRoaXMgaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByYWN0aWNhbCBp biB0aGUgc2hvcnQgdGVybSwgYW5kIGl0IGFsc28gaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNv bHZpbmcgdGhlIGRpc3RpbmN0IGlzc3VlciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbms8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdGhpcyBpcyBzb21ldGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91 c2x5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNpZGVyLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhvdWdodHM/PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBNYXJpdXM8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IElkLWV2ZW50 IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsNCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2 ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4 UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJ Q0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1w O3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1 dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJ ajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmYW1wO2U9PC9hPjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQt ZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3 bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlf M3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01T V1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAtLSA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBZGFtIERhd2VzIHwgU3IuIFByb2R1Y3QgTWFuYWdlciB8PGEgaHJlZj0i bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5j b208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHw8YSBocmVmPSJ0ZWw6JTJCMSUyMDY1MC0yMTQt MjQxMCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7MSA2NTAtMjE0LTI0MTA8L2E+PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9InRlbDolMjg2 NTAlMjklMjAyMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsiPnRlbDooNjUwKSUyMDIxNC0yNDEwPC9h PiZndDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcg bGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGll dGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAw WV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1H TVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAtLSA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3Vic2NyaWJlIHRv IHRoZSBIQVJEVFdBUkUgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlS ckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNo bVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9aTc1VXc4YWVoWXZscElaTkw3Tnhx R3hoaDFUT3JRT1VYMlhNWUJlclY4MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vaGFy ZHR3YXJlLmNvbS88L2E+Jmd0Ow0KIG1haWwgbGlzdCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUg Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdK eFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQt MDBZXzN6Um9haTExNWMmYW1wO3M9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhN WUJlclY4MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vaGFyZHR3YXJlLmNvbS88L2E+ Jmd0Ow0KIG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24h PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3 bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7 ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDtt PVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVH enNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpq V3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pS b2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dz JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1w O3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT08L2E+ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ SWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVu dCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPklk LWV2ZW50QGlldGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B93EF6E64D6F4A18A6EE9EF28FC21C1Bamazoncom_-- From nobody Wed Jun 21 13:59:00 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D713129484 for ; Wed, 21 Jun 2017 13:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg-IVcMnOeuj for ; Wed, 21 Jun 2017 13:58:52 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605291274D2 for ; Wed, 21 Jun 2017 13:58:52 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id h134so3169284iof.2 for ; Wed, 21 Jun 2017 13:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vF13nnMWgZQJ58Qbo4t6UhpASRHnAjC4m0aHSlOZmf0=; b=CzE2BJvfMi5l6sbDBcAW/Sl8wT3aCC1Urxc2RROPG6LWy1PrAMaaOqeXHovMAAQjlE xZaRxq55xCpkLi4jL9PNEg/ukypeHR2svmf2doVivYwutF61wFIdWN2fXdTmczC8xAgz 2/Tv8zHOP3AjbxFnk+ERzfdBC5GLgplkYfc+hMmoUQDMH6DLX1J64C0yDTZZvRlYXHNu Y+eer6rN1kiA7gZf5e5UrZYOCkEVGNgPjVm5MlvFSx3sBksJSBZBJS6VF2/B0GK/Kppk 2Q8jzryFyyLRJ2yHPvWjyqKgAXAOwnMgm4Brbum7ZDtHOzJPmz3z6zoSNq1jsO/phBCf iA0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vF13nnMWgZQJ58Qbo4t6UhpASRHnAjC4m0aHSlOZmf0=; b=qLnKUd9nfrTHkhAWoebakRcmrK+haUAFdqK9qlkQiSXNX8OwJx9u54/wlVTPbenmar GQKV7Aro5QOtlUt7fmS5HCG28jYA83EXi9L3jP47O9xF72L+xGH3yoBoQg9CtDzXgHy9 rsVZnErhF5H9SAJvCC77NXn7uFQ/hKKBPh5714Giq1ktuc0tjiPBDNmNGb3kJQPBUTyZ wJaDYd+Dh7j3nhaKGWRlAGzIjdEsC7/GLgUnRPxDhVa/GsTixtJtJjqIY2oca4Zgsiy6 7B9ojNIUTJtFXEj+euQoZRKJOyvIbVty0I58B2WrBy+sSIiyDVMWidz5F2ZV+snfT8+0 DtRw== X-Gm-Message-State: AKS2vOxpVGp3QKEcg7RnfJQW7Rf822SL2JGh8VKn37y67BN/fV8MduhY /gkeLLzDyxGbRS8z X-Received: by 10.107.171.67 with SMTP id u64mr31664607ioe.125.1498078731420; Wed, 21 Jun 2017 13:58:51 -0700 (PDT) Received: from [10.150.72.61] ([208.59.64.22]) by smtp.gmail.com with ESMTPSA id h187sm3258003itb.13.2017.06.21.13.58.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 13:58:50 -0700 (PDT) From: John Bradley Message-Id: <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 21 Jun 2017 15:58:49 -0500 In-Reply-To: Cc: Yaron Sheffer , Justin Richer , Marius Scurtescu , Phil Hunt , Michael Jones , ID Events Mailing List , Henk Birkholz To: Annabelle Richard References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c059e14a81e5a05527ea277" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:58:59 -0000 --94eb2c059e14a81e5a05527ea277 Content-Type: multipart/alternative; boundary="Apple-Mail=_B42977B3-3AD8-4F53-A7BA-6EF19036D151" --Apple-Mail=_B42977B3-3AD8-4F53-A7BA-6EF19036D151 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thought we decided that we are only allowing set messages form the = same family that agree on top level claims. Otherwise there can be no top level claims and we are really defining a = alternative format to JWT in some ways. John B. > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle = wrote: >=20 > I agree with John that the JWT type confusion problem and the SET sub = problem can and should be discussed separately. The secevents WG is = probably not the right setting to discuss the former. > =20 > My concern with the sub claim is that two profiles may dictate = conflicting semantics (e.g. Profile A says it=E2=80=99s a phone number, = Profile B says it=E2=80=99s an email address). If these profiles don=E2=80= =99t provide an alternate way to declare subject of their events, then = they cannot be present within the same token. This incompatibility trap = seems like something that could be easily missed by groups profiling = SET. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: John Bradley > Date: Wednesday, June 21, 2017 at 1:39 PM > To: Yaron Sheffer > Cc: Justin Richer , Marius Scurtescu = , Annabelle Richard , Phil = Hunt , Michael Jones = , ID Events Mailing List = , Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > In the envelope typ is a media/mime type. Registering = application/idt+jwt if we register jwt as a structured name sufix. =20 > =20 > Using the cty is also possible. I need to think about what is better = but we can agree on a convention. > =20 > Not everything is going to be a set token like not every JWS is a JWT. > =20 > If we are going to define processing rules to stop collisions and = confusion around JWT for different purposes, we should just start using = the typ parameter based on the existing spec. > =20 > In general content sniffing if there is more than one option = eventually gets you into trouble. > =20 > I am not convinced that forcing there to be no sub at the top level is = a good idea. =20 > =20 > It is not the way we should differentiate between SET and id_tokens. > =20 > If sub is not allowed at the top level people will do non SET JWT for = things where the subject is scoped to the iss of the token. > =20 > I think defining sub to be part of the event for cases where the sub = is scoped differently from the issuer of the token is fine, but should = not be required for all event types. > =20 > I think we should solve the confusion issue separately from the sub = issue. > =20 > Sorry I am at CIS so trying to catch up on lists. > =20 > John B. > =20 >> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer > wrote: >> =20 >> So to summarize what I'm seeing on this thread: >> Everybody agrees with Marius's short-term solution, specific rules = for "sub" and "iss" that can be defined in the SET spec. >> Almost everybody agrees on a long-term "usage" claim ("type" is = taken) that should be defined elsewhere, e.g. in the JWT BCP. >> Did I miss anything? >> By the way, if we do add a "usage" claim, we need to also use it in = the SET document before it is published. >> Thanks, >> Yaron >> =20 >> On 15/06/17 22:08, Justin Richer wrote: >>> +1 to this as well.=20 >>> =20 >>> =E2=80=94 Justin >>> =20 >>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu = > wrote: >>>> =20 >>>> +1 to what Annabelle said.=20 >>>> =20 >>>> Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >>>>=20 >>>> Marius >>>> =20 >>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) = > wrote: >>>>> +1 >>>>> =20 >>>>> Phil >>>>>=20 >>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >>>>>=20 >>>>>> Mike, >>>>>> =20 >>>>>> Your explanation for why this is a non-problem is dependent upon = side effects of elements of OpenID Connect that were not designed to = solve this issue. As a result, I see several issues with it: >>>>>> 1. The caller of the Token Endpoint is the only party that = can be certain that a nonce-less ID Token is really an ID Token. Any = party that the caller passes the ID Token off to has no way to verify = its provenance. >>>>>>=20 >>>>>> 2. Any future ID Token distribution method needs to solve = this problem again. >>>>>>=20 >>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >>>>>>=20 >>>>>> 4. This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem. >>>>>>=20 >>>>>> =20 >>>>>> We know from experience that naming collisions and replay attacks = are both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. >>>>>> =20 >>>>>> --=20 >>>>>> Annabelle Richard Backman >>>>>> Identity Services >>>>>> =20 >>>>>> =20 >>>>>> From: Id-event > on behalf of Mike Jones = > >>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>> To: Marius Scurtescu > >>>>>> Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>> =20 >>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematu= re pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >>>>>> =20 >>>>>> Mandatory solutions are being proposed in this thread to problems = that there=E2=80=99s no evidence that we actually even have. It=E2=80=99s= already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >>>>>> =20 >>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the = use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type = claim, would make previously simple things unnecessarily complex. Yes, = then the result is then different than a normal JWT but a consequence of = this is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. >>>>>> =20 >>>>>> -- Mike >>>>>> =20 >>>>>> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle >>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>> To: Marius Scurtescu >; Henk Birkholz = > >>>>>> Cc: ID Events Mailing List > >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>> =20 >>>>>> Echoing Marius=E2=80=99s question: can you explain what you mean = by =E2=80=9Cintend=E2=80=9D? >>>>>> =20 >>>>>> To your first question, I think a better analogy would be the = X.509 Key Usage extension: a multi-valued property that declares the = intended purpose of the JWT, and that a recipient may refer to when = determining whether to accept a JWT being presented to it in some = context. >>>>>> =20 >>>>>> --=20 >>>>>> Annabelle Richard Backman >>>>>> Identity Services >>>>>> =20 >>>>>> =20 >>>>>> From: Id-event > on behalf of Marius Scurtescu = > >>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>> To: Henk Birkholz > >>>>>> Cc: ID Events Mailing List > >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>> =20 >>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >>>>>>> And a 2nd question. >>>>>>>=20 >>>>>>> What semantics would "usage" provide that that are not covered = via "intend", "audience", and "scope"? >>>>>> =20 >>>>>> "aud" (audience) specifies the target client, but not the = intended usage (access token to authorize resource access or SET to = communicate a security event?) >>>>>> =20 >>>>>> "scope" is not used by SET. >>>>>> =20 >>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>> =20 >>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Henk >>>>>>>=20 >>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>> Thanks for putting this together! >>>>>>>>=20 >>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>=20 >>>>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will = have a mutually exclusive set of valid claims and/or header parameters, = and enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80= =9D approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >>>>>>>>=20 >>>>>>>> =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >>>>>>>>=20 >>>>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >>>>>>>>=20 >>>>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Annabelle Richard Backman >>>>>>>>=20 >>>>>>>> Identity Services >>>>>>>>=20 >>>>>>>> *From: *Id-event > on behalf of Dick Hardt = > >>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>> *To: *Marius Scurtescu > >>>>>>>> *Cc: *Adam Dawes >, "matake, nov" >, ID Events Mailing List >, "Phil Hunt (IDM)" > >>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer >>>>>>>>=20 >>>>>>>> Agreed. Note that there is still lots of discussion on what = should be in 3.9. >>>>>>>>=20 >>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = >> wrote: >>>>>>>>=20 >>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>=20 >>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" and = the >>>>>>>> mitigation is in "3.9. Use Mutually Exclusive Validation = Rules for >>>>>>>> Different Kinds of JWTs", specifically "Use different sets = of >>>>>>>> required claims...", "Use different keys for different = kinds of >>>>>>>> JWTs." and "Use different issuers for different kinds of = JWTs.". >>>>>>>>=20 >>>>>>>> I still think that a "type" claim would bring a lot of = clarity and >>>>>>>> safety. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Marius >>>>>>>>=20 >>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt = >>>>>>>> >> wrote: >>>>>>>>=20 >>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>> http://self-issued.info/?p=3D1690 = >>>>>>>>=20 >>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes = >>>>>>>> >> = wrote: >>>>>>>>=20 >>>>>>>> I was initially a fan of keeping SETS to be very = similar to >>>>>>>> id tokens but I now think this is a better plan. >>>>>>>>=20 >>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov = >>>>>>>> >> = wrote: >>>>>>>>=20 >>>>>>>> +1 especially for "type" >>>>>>>>=20 >>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>> >>: >>>>>>>>=20 >>>>>>>> +1 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius = Scurtescu >>>>>>>> >>>>>>>> >> wrote: >>>>>>>> > >>>>>>>> > There were a couple of proposals on how = to >>>>>>>> distinguish SETs from Id Tokens and Access = Tokens in >>>>>>>> such a way that naive implementations will = not >>>>>>>> confuse one for the other and open up = security >>>>>>>> vulnerabilities. >>>>>>>> > >>>>>>>> > There is also another important = requirement: the >>>>>>>> SET issuer in some cases must be different = from the >>>>>>>> "sub" issuer. This is the case of an RP = sending SETs >>>>>>>> to an IdP. >>>>>>>> > >>>>>>>> > With these requirements in mind I = propose the >>>>>>>> following: >>>>>>>> > - both "sub" and "iss" to be defined at = the event >>>>>>>> level >>>>>>>> > - "iss" at event level and at top SET = level can >>>>>>>> be different >>>>>>>> > - "iss" and "sub" at event level can be = different >>>>>>>> across events in the same SET >>>>>>>> > - "sub" should NOT be present at the top = SET >>>>>>>> level (this solves the disambiguation), = please note >>>>>>>> "should" and not "must" >>>>>>>> > >>>>>>>> > This solution also allows different = profiles that >>>>>>>> define event types to define additional = claims >>>>>>>> related to sub (like email or phone_number) = and >>>>>>>> since all these claims will be at the event = level >>>>>>>> there will be no collisions or ambiguity. >>>>>>>> > >>>>>>>> > Another proposal (which I supported) was = to >>>>>>>> define a composite "aud" claim. This is not = solving >>>>>>>> the requirement for a distinct SET issuer. = Also, >>>>>>>> having the same claim name having different = syntax >>>>>>>> in different token types could lead to = confusion. >>>>>>>> > >>>>>>>> > And yet another proposal was to = introduce a new >>>>>>>> claim for JWTs that defines a "type". This = is not >>>>>>>> practical in the short term, and it also is = not >>>>>>>> solving the distinct issuer requirement, = but I think >>>>>>>> this is something the JWT group should = seriously >>>>>>>> consider. >>>>>>>> > >>>>>>>> > Thoughts? >>>>>>>> > >>>>>>>> > Marius >>>>>>>>=20 >>>>>>>> > = _______________________________________________ >>>>>>>> > Id-event mailing list >>>>>>>> > Id-event@ietf.org = > >>>>>>>> > >>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >>>>>>>>=20 >>>>>>>> = _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org = > >>>>>>>> = https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org = > >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Adam Dawes | Sr. Product Manager |adawes@google.com = >>>>>>>> > |+1 650-214-2410 >>>>>>>> > >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org = > >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Subscribe to the HARDTWARE > mail list to >>>>>>>> learn about projects I am working on! >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>>=20 >>>>>>>> Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>> =20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = >>>> =20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event = >>> =20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = =20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 > =20 --Apple-Mail=_B42977B3-3AD8-4F53-A7BA-6EF19036D151 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I thought we decided that we are only allowing set messages = form the same family that agree on top level claims.

Otherwise there can be no top level = claims and we are really defining a alternative format to JWT in some = ways.

John = B.

On Jun 21, 2017, at 3:54 PM, Richard Backman, = Annabelle <richanna@amazon.com> wrote:

I = agree with John that the JWT type confusion problem and the SET sub = problem can and should be discussed separately. The secevents WG is = probably not the right setting to discuss the former.
 
My concern with the sub claim is that two = profiles may dictate conflicting semantics (e.g. Profile A says it=E2=80=99= s a phone number, Profile B says it=E2=80=99s an email address). If = these profiles don=E2=80=99t provide an alternate way to declare subject = of their events, then they cannot be present within the same token. This = incompatibility trap seems like something that could be easily missed by = groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: John Bradley = <ve7jtb@ve7jtb.com>
Date: Wednesday, June 21, = 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, = Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
In the envelope typ is a media/mime type. =  Registering application/idt+jwt if we register jwt as a structured = name sufix.  
 
Using the cty is also possible.   I need to = think about what is better but we can agree on a convention.
 
Not everything is going to be a set token like not = every JWS is a JWT.
 
If we are going to define processing rules to stop = collisions and confusion around JWT for different purposes, we should = just start using the typ parameter based on the existing spec.
 
In general content sniffing if there is = more than one option eventually gets you into trouble.
 
I am not convinced that forcing there to = be no sub at the top level is a good idea.  
 
It is not the way we should differentiate = between SET and id_tokens.
 
If sub is not allowed at the top level people will do = non SET JWT for things where the subject is scoped to the iss of the = token.
 
I think defining sub to be part of the event for = cases where the sub is scoped differently from the issuer of the token = is fine, but should not be required for all event types.
 
I think we should solve the confusion = issue separately from the sub issue.
 
Sorry I am at CIS so trying to catch up on lists.
 
John B.
 
On = Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:
 
So to summarize what = I'm seeing on this thread:
Everybody agrees with Marius's short-term = solution, specific rules for "sub" and "iss" that can be defined in the = SET spec.
Almost everybody agrees on a long-term "usage" claim ("type" = is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did = I miss anything?
By the way, if we do add a "usage" claim, we need to also use = it in the SET document before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, = Justin Richer wrote:
+1 to this as = well. 
 
 =E2=80=94 Justin
 
On = Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> = wrote:
 
+1 to what Annabelle = said. 
 
Also, Mike you are missing the other = requirement, for RPs to send events to an IdP. The iss+sub pair at the = top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
 
Phil


On Jun 14, 2017, at 5:25 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:

Mike,
 
Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with = it:

1.       The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance.

2.       Any future ID Token distribution method needs to solve this = problem again.

3.      No= other profile of JWT can ever use the "nonce=E2=80=9D claim.

4.      This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem.

 
We= know from experience that naming collisions and replay attacks are both = things that happen. What=E2=80=99s being proposed is a simple, defensive = measure against these risks. You brought up JWT libraries: a general = solution actually makes it easier to use common libraries for JWT = parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones = <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, = 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, = Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>,= Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
You=E2=80=99ve heard of =E2=80=9Cpremature = optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in = this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making = things that can and should be simple complex, without data showing = there=E2=80=99s any need to do so.
 
Mandatory solutions are = being proposed in this thread to problems that there=E2=80=99s no = evidence that we actually even have.  It=E2=80=99s already been = established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428= .html.  If people have data showing that this is possible with = specific kinds of Access Tokens or other real JWT deployments, please = provide specifics, so that we can use that data to inform appropriate = engineering choices on our part.
 
The proposed = =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2= =80=9D in the normal way, or requiring a type claim, would make = previously simple things unnecessarily complex.  Yes, then the = result is then different than a normal JWT but a consequence of this is = that custom parsing code would have to be used, rather than a standard = JWT parser.  The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures.  = Keeping it simple is the key to adoption.  Standards are only = useful if they are actually used.
 
          &nb= sp;            = ;            &= nbsp;            = -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf = Of Richard = Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 = PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID = Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for = Id/Access Token confusion and distinct SET issuer
 
Echoing Marius=E2=80=99s = question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?
 
To= your first question, I think a better analogy would be the X.509 Key = Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some = context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 = at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID = Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
On Tue, Jun 13, 2017 = at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd = question.

What semantics would "usage" = provide that that are not covered via "intend", "audience", and = "scope"?
 
"aud" (audience) specifies the target client, but not = the intended usage (access token to authorize resource access or SET to = communicate a security event?)
 
"scope" is not used = by SET.
 
I don't know what do you mean by "intend" (or = intent)?
 
 


Henk

On = 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting = this together!

I think the assumptions = inherent in 3.9 are flawed:

=C2=B7We = can=E2=80=99t guarantee that every type of JWT will have a mutually = exclusive set of valid claims and/or header parameters, and enforcing = this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach = to ensure that JWTs from some future spec can=E2=80=99t be mistaken for = JWTs from a current spec.

=C2=B7It is = unrealistic to expect implementers to adhere to the =E2=80=9Cdifferent = keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by the = spec or not, implementers will ignore this because managing one key is = easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D= claims.

+1 for a =E2=80=9Ctype=E2=80=9D or = =E2=80=9Cusage=E2=80=9D claim/header parameter.

-- 

Annabelle Richard Backman

Identity Services

*From: = *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
*Date: *Monday, = June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes = <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events = Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer

Agreed. Note that there is still = lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing = :-)

    The issue is described by = "2.7. Cross-JWT Confusion" and the
    = mitigation is in "3.9. Use Mutually Exclusive Validation Rules for
    Different Kinds of JWTs", specifically "Use = different sets of
    required claims...", "Use = different keys for different kinds of
    JWTs." = and "Use different issuers for different kinds of JWTs.".

    I still think that a "type" = claim would bring a lot of clarity and
    = safety.


    = Marius

    On Thu, Jun 8, 2017 at = 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    = <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published = an BCP ID for JWT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM = Adam Dawes <adawes@google.com
      =   <mailto:adawes@google.com>> wrote:

            I was initially a = fan of keeping SETS to be very similar to
    =         id tokens but I now think this is a better = plan.

          =   On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
            <mailto:nov@matake.jp>> = wrote:

          =       +1 especially for "type"

                = 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
    =             <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

                =     +1

      =               Phil


            =          > On Jun 8, 2017, at 6:28 PM, = Marius Scurtescu
            =         <mscurtescu@google.com
 =                   = <mailto:mscurtescu@google.com>> wrote:
  =                   =  >
            =          > There were a couple of proposals = on how to
              =       distinguish SETs from Id Tokens and Access Tokens = in
                =     such a way that naive implementations will not
                =     confuse one for the other and open up security
                =     vulnerabilities.
        =              >
  =                   =  > There is also another important requirement: the
                =     SET issuer in some cases must be different from the
                =     "sub" issuer. This is the case of an RP sending SETs
                =     to an IdP.
        =              >
  =                   =  > With these requirements in mind I propose the
                =     following:
        =              > - both "sub" and = "iss" to be defined at the event
      =               level
                =      > - "iss" at event level and at top SET level = can
              =       be different
      =                > - "iss" and = "sub" at event level can be different
      =               across events in the = same SET
              =        > - "sub" should NOT be present at the top = SET
              =       level (this solves the disambiguation), please = note
              =       "should" and not "must"
    =                  >
                =      > This solution also allows different profiles = that
              =       define event types to define additional claims
                =     related to sub (like email or phone_number) and
                =     since all these claims will be at the event level
                =     there will be no collisions or ambiguity.
                =      >
        =              > Another proposal = (which I supported) was to
        =             define a composite "aud" = claim. This is not solving
        =             the requirement for a = distinct  SET issuer. Also,
      =               having the same claim = name having different syntax
        =             in different token types could = lead to confusion.
          =            >
  =                   =  > And yet another proposal was to introduce a new
                =     claim for JWTs that defines a "type". This is not
                =     practical in the short term, and it also is not
                =     solving the distinct issuer requirement, but I think
                =     this is something the JWT group should seriously
                =     consider.
          =            >
  =                   =  > Thoughts?
          =            >
  =                   =  > Marius

      =                > = _______________________________________________
  =                   =  > Id-event mailing list
        =              > Id-event@ietf.org <mailto:Id-event@ietf.org>
      =                >
                =     https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6= Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                =     _______________________________________________
                =     Id-event mailing list
      =               Id-event@ietf.org <mailto:Id-event@ietf.org>
      =               https://www.ietf.org/mailman/listinfo/id-event

            =     _______________________________________________
                = Id-event mailing list
          =       Id-event@ietf.org <mailto:Id-event@ietf.org>
      =           https://www.ietf.org/mailman/listinfo/id-event

            = -- 
 =           Adam Dawes | Sr. Product Manager |adawes@google.com
            <mailto:adawes@google.com> = |+1 650-214-2410
            <tel:(650)%20214-2410>

            = _______________________________________________
  =           Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
      =       https://www.ietf.org/mailman/listinfo/id-event

        -- 
  =       Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working = on!



-- 

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn = about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 



_______________________________________________
Id-event =
mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 

= --Apple-Mail=_B42977B3-3AD8-4F53-A7BA-6EF19036D151-- --94eb2c059e14a81e5a05527ea277 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIEM8mledR2YpJi4wHrfAcX5mooqM sv062oSZ6N+wc6nzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYyMTIwNTg1MVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQDJmWu5+RP9N49BBBH9ZnXlerD/Yth9QQcFpa/DzgqSD3+i BtMpjiicdcvOfg0u/YDKc/A5HFgdLUg8Cv+TeSYAyxzXjju5mswce5GzxDQXBTiDIh7ECaUTHMsp LsnvomiAkzWI0a/Nq86NLEVIerM0RIHHEgtaljRp4zvuYbT5tyLD9ttAjqKaBtZ4zSF4KeobNUss TWECy30gMepvggUdjrMvJ3bg8wA3jZFI6GgGjUEffddBSvz2KV8UT4by1DF2dkYq0z6/cw5pC5PT 3FsK0k5Oc3k5mU/IsrDWQSLbVwcucRhMIs78lN0BRQjnY7wt1ZSby0nEmR7a4dPffhKB --94eb2c059e14a81e5a05527ea277-- From nobody Wed Jun 21 14:03:55 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50F1294A4 for ; Wed, 21 Jun 2017 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKDMXGQjDPD1 for ; Wed, 21 Jun 2017 14:03:49 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4711274D2 for ; Wed, 21 Jun 2017 14:03:49 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5LL3h2f023317 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 21:03:43 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5LL3gM4001286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 21:03:42 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5LL3ctj025632; Wed, 21 Jun 2017 21:03:39 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jun 2017 14:03:37 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-57E11D16-9513-4881-8DD3-1B1D8AEC42B0 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> Date: Wed, 21 Jun 2017 14:03:35 -0700 Cc: Yaron Sheffer , Annabelle Richard , Henk Birkholz , Justin Richer , Marius Scurtescu , Michael Jones , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <4FE89921-E010-463E-B56F-95C0C23838C7@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39! @mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> To: John Bradley X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:03:54 -0000 --Apple-Mail-57E11D16-9513-4881-8DD3-1B1D8AEC42B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are several problems that moving sub is w to. Note some of these may b= e somewhat conflicting but i wanted to get the out on the table... 1. Typing: Since there is no strong typing, moving sub from top level ensure= s the existing code should reject SETs. Yes we can also use the typing propo= sal in the header. The concern seems to be that existing implementations wil= l ignore.=20 2. Hard differentiator: Since sub's common usage is not globally unique, it o= ften needs to be bound to an issuer for sub. The current draft works well if= set issuer and sub issuer happen to be the same. But as far as I can tell r= eviewing the use cases this is only true for the current logout spec. 3. Consistency for Events: Having varying rules per spec at the top level me= ans lack of interop. Many implementers expect to process provisioning, risk,= and session management events through the same systems. To get around this d= eployers would have to deploy many more streams with specific logic generati= ng potentially big pile of spaghetti architecture.=20 4. Common usage practice: Should sub be used for other purposes? Eg a secur= ity event about an ipaddress? Is it better to encourage profilers to avoid r= e-using sub at the top level and use a domain specific claim like ipaddresss= ? Do we profile any use of sub at the top level to be globally unique and s= elf defining? Eg. "Sub":"urn:ietf:params:set:ipaddress:1.2.3.4" Did I miss any? Phil > On Jun 21, 2017, at 1:39 PM, John Bradley wrote: >=20 > In the envelope typ is a media/mime type. Registering application/idt+jwt= if we register jwt as a structured name sufix. =20 >=20 > Using the cty is also possible. I need to think about what is better but= we can agree on a convention. >=20 > Not everything is going to be a set token like not every JWS is a JWT. >=20 > If we are going to define processing rules to stop collisions and confusio= n around JWT for different purposes, we should just start using the typ para= meter based on the existing spec. >=20 > In general content sniffing if there is more than one option eventually ge= ts you into trouble. >=20 > I am not convinced that forcing there to be no sub at the top level is a g= ood idea. =20 >=20 > It is not the way we should differentiate between SET and id_tokens. >=20 > If sub is not allowed at the top level people will do non SET JWT for thin= gs where the subject is scoped to the iss of the token. >=20 > I think defining sub to be part of the event for cases where the sub is sc= oped differently from the issuer of the token is fine, but should not be req= uired for all event types. >=20 > I think we should solve the confusion issue separately from the sub issue.= >=20 > Sorry I am at CIS so trying to catch up on lists. >=20 > John B. >=20 >> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote:= >>=20 >> So to summarize what I'm seeing on this thread: >>=20 >> Everybody agrees with Marius's short-term solution, specific rules for "s= ub" and "iss" that can be defined in the SET spec. >>=20 >> Almost everybody agrees on a long-term "usage" claim ("type" is taken) th= at should be defined elsewhere, e.g. in the JWT BCP. >> Did I miss anything? >>=20 >> By the way, if we do add a "usage" claim, we need to also use it in the S= ET document before it is published. >> Thanks, >>=20 >> Yaron >>=20 >>> On 15/06/17 22:08, Justin Richer wrote: >>> +1 to this as well. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu w= rote: >>>>=20 >>>> +1 to what Annabelle said. >>>>=20 >>>> Also, Mike you are missing the other requirement, for RPs to send event= s to an IdP. The iss+sub pair at the top level is broken in this case. >>>>=20 >>>> Marius >>>>=20 >>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wrote: >>>>> +1 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >>>>>=20 >>>>>> Mike, >>>>>>=20 >>>>>> =20 >>>>>> Your explanation for why this is a non-problem is dependent upon side= effects of elements of OpenID Connect that were not designed to solve this i= ssue. As a result, I see several issues with it: >>>>>>=20 >>>>>> 1. The caller of the Token Endpoint is the only party that can b= e certain that a nonce-less ID Token is really an ID Token. Any party that t= he caller passes the ID Token off to has no way to verify its provenance. >>>>>>=20 >>>>>> 2. Any future ID Token distribution method needs to solve this p= roblem again. >>>>>>=20 >>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D clai= m. >>>>>>=20 >>>>>> 4. This is only a solution for ID Tokens. Every other JWT profil= e that cares about disambiguation has to invent its own solution to the prob= lem. >>>>>>=20 >>>>>> =20 >>>>>> We know from experience that naming collisions and replay attacks are= both things that happen. What=E2=80=99s being proposed is a simple, defensi= ve measure against these risks. You brought up JWT libraries: a general solu= tion actually makes it easier to use common libraries for JWT parsing. A =E2= =80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for any J= WT profile, whereas with the status quo each profile would require unique lo= gic. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> Identity Services >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: Id-event on behalf of Mike Jones >>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>> To: Marius Scurtescu >>>>>> Cc: "Richard Backman, Annabelle" , ID Events Mai= ling List , Henk Birkholz >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer >>>>>>=20 >>>>>> =20 >>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals in this thread as =E2=80=9Cpremature pess= imation=E2=80=9D =E2=80=93 making things that can and should be simple compl= ex, without data showing there=E2=80=99s any need to do so. >>>>>>=20 >>>>>> =20 >>>>>> Mandatory solutions are being proposed in this thread to problems tha= t there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alre= ady been established that it=E2=80=99s impossible for a SET to be confused f= or an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/= current/msg00428.html. If people have data showing that this is possible wi= th specific kinds of Access Tokens or other real JWT deployments, please pro= vide specifics, so that we can use that data to inform appropriate engineeri= ng choices on our part. >>>>>>=20 >>>>>> =20 >>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use= of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, woul= d make previously simple things unnecessarily complex. Yes, then the result= is then different than a normal JWT but a consequence of this is that custo= m parsing code would have to be used, rather than a standard JWT parser. Th= e more unwieldy we make it to use SETs, the more likely developers are to ju= st create their own data structures. Keeping it simple is the key to adopti= on. Standards are only useful if they are actually used. >>>>>>=20 >>>>>> =20 >>>>>> -- Mike >>>>>>=20 >>>>>> =20 >>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richar= d Backman, Annabelle >>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>> To: Marius Scurtescu ; Henk Birkholz >>>>>> Cc: ID Events Mailing List >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer >>>>>>=20 >>>>>> =20 >>>>>> Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? >>>>>>=20 >>>>>> =20 >>>>>> To your first question, I think a better analogy would be the X.509 K= ey Usage extension: a multi-valued property that declares the intended purpo= se of the JWT, and that a recipient may refer to when determining whether to= accept a JWT being presented to it in some context. >>>>>>=20 >>>>>> =20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> Identity Services >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: Id-event on behalf of Marius Scurte= scu >>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>> To: Henk Birkholz >>>>>> Cc: ID Events Mailing List >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer >>>>>>=20 >>>>>> =20 >>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: >>>>>>=20 >>>>>> And a 2nd question. >>>>>>=20 >>>>>> What semantics would "usage" provide that that are not covered via "i= ntend", "audience", and "scope"? >>>>>>=20 >>>>>> =20 >>>>>> "aud" (audience) specifies the target client, but not the intended us= age (access token to authorize resource access or SET to communicate a secur= ity event?) >>>>>>=20 >>>>>> =20 >>>>>> "scope" is not used by SET. >>>>>>=20 >>>>>> =20 >>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>> Henk >>>>>>=20 >>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>=20 >>>>>> Thanks for putting this together! >>>>>>=20 >>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>=20 >>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a m= utually exclusive set of valid claims and/or header parameters, and enforcin= g this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach t= o ensure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs f= rom a current spec. >>>>>>=20 >>>>>> =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80= =9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandate= d by the spec or not, implementers will ignore this because managing one key= is easier than managing N different keys. >>>>>>=20 >>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claim= s. >>>>>>=20 >>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/head= er parameter. >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> Identity Services >>>>>>=20 >>>>>> *From: *Id-event on behalf of Dick Hardt <= dick.hardt@gmail.com> >>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>> *To: *Marius Scurtescu >>>>>> *Cc: *Adam Dawes , = "matake, nov" , ID Events Mailing List , "Phil Hunt (IDM)" >>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer >>>>>>=20 >>>>>> Agreed. Note that there is still lots of discussion on what should be= in 3.9. >>>>>>=20 >>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >>>>>>=20 >>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>=20 >>>>>> The issue is described by "2.7. Cross-JWT = Confusion" and the >>>>>> mitigation is in "3.9. Use Mutually Exclusive Validation Rules fo= r >>>>>> Different Kinds of JWTs", specifically "Use different sets of >>>>>> required claims...", "Use different keys for different kinds of >>>>>> JWTs." and "Use different issuers for different kinds of JWTs.". >>>>>>=20 >>>>>> I still think that a "type" claim would bring a lot of clarity an= d >>>>>> safety. >>>>>>=20 >>>>>>=20 >>>>>> Marius >>>>>>=20 >>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>>>> > wrote: >>>>>>=20 >>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>> http://self-issued.info/?p=3D1690 >>>>>>=20 >>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>>>> > wrote: >>>>>>=20 >>>>>> I was initially a fan of keeping SETS to be very similar t= o >>>>>> id tokens but I now think this is a better plan. >>>>>>=20 >>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>>>> > wrote: >>>>>>=20 >>>>>> +1 especially for "type" >>>>>>=20 >>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>> >:= >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>=20 >>>>>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >>>>>> >>>>>=20 >>>>>> > wrote: >>>>>> > >>>>>> > There were a couple of proposals on how to >>>>>> distinguish SETs from Id Tokens and Access Tokens= in >>>>>> such a way that naive implementations will not >>>>>> confuse one for the other and open up security >>>>>> vulnerabilities. >>>>>> > >>>>>> > There is also another important requirement: t= he >>>>>> SET issuer in some cases must be different from t= he >>>>>> "sub" issuer. This is the case of an RP sending S= ETs >>>>>> to an IdP. >>>>>> > >>>>>> > With these requirements in mind I propose the >>>>>> following: >>>>>> > - both "sub" and "iss" to be defined at the ev= ent >>>>>> level >>>>>> > - "iss" at event level and at top SET level ca= n >>>>>> be different >>>>>> > - "iss" and "sub" at event level can be differ= ent >>>>>> across events in the same SET >>>>>> > - "sub" should NOT be present at the top SET >>>>>> level (this solves the disambiguation), please no= te >>>>>> "should" and not "must" >>>>>> > >>>>>> > This solution also allows different profiles t= hat >>>>>> define event types to define additional claims >>>>>> related to sub (like email or phone_number) and >>>>>> since all these claims will be at the event level= >>>>>> there will be no collisions or ambiguity. >>>>>> > >>>>>> > Another proposal (which I supported) was to >>>>>> define a composite "aud" claim. This is not solvi= ng >>>>>> the requirement for a distinct SET issuer. Also,= >>>>>> having the same claim name having different synta= x >>>>>> in different token types could lead to confusion.= >>>>>> > >>>>>> > And yet another proposal was to introduce a ne= w >>>>>> claim for JWTs that defines a "type". This is not= >>>>>> practical in the short term, and it also is not >>>>>> solving the distinct issuer requirement, but I th= ink >>>>>> this is something the JWT group should seriously >>>>>> consider. >>>>>> > >>>>>> > Thoughts? >>>>>> > >>>>>> > Marius >>>>>>=20 >>>>>> > ______________________________________________= _ >>>>>> > Id-event mailing list >>>>>>=20 >>>>>> > Id-event@ietf.org >>>>>> > >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp= s-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWH= vlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIG= k&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoV= pn88YKOCd0mxPQFJLhxWI&e=3D >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>> --=20 >>>>>> Adam Dawes | Sr. Product Manager |adawes@google.com >>>>>> |+1 650-214-2410 >>>>>> >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>> --=20 >>>>>> Subscribe to the HARDTWARE mail list t= o >>>>>> learn about projects I am working on! >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Subscribe to the HARDTWARE mail list to learn= about projects I am working on! >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>> =20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkK= Y057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHsh= mQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWW= s&e=3D=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 --Apple-Mail-57E11D16-9513-4881-8DD3-1B1D8AEC42B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There are several problems that moving= sub is w to. Note some of these may be somewhat conflicting but i wanted to= get the out on the table...

<= div id=3D"AppleMailSignature">1. Typing: Since there is no strong typing, mo= ving sub from top level ensures the existing code should reject SETs. Yes we= can also use the typing proposal in the header. The concern seems to be tha= t existing implementations will ignore. 

2. Hard differentiator: Since= sub's common usage is not globally unique, it often needs to be bound to an= issuer for sub. The current draft works well if set issuer and sub issuer h= appen to be the same. But as far as I can tell reviewing the use cases this i= s only true for the current logout spec.

3. Consistency for Events: Having v= arying rules per spec at the top level means lack of interop. Many implement= ers expect to process provisioning, risk, and session management events thro= ugh the same systems. To get around this deployers would have to deploy many= more streams with specific logic generating potentially big pile of spaghet= ti architecture. 

4. Common usage practice: Should sub be used for oth= er purposes?  Eg a security event about an ipaddress? Is it better to e= ncourage profilers to avoid re-using sub at the top level and use a domain s= pecific claim like ipaddresss?  Do we profile any use of sub at the top= level to be globally unique and self defining?
Eg. "Sub":"urn:ietf:params:set:ipaddress:1.2.3.4"

Did I miss a= ny?

Phil

On Jun 21, 20= 17, at 1:39 PM, John Bradley <ve7jtb= @ve7jtb.com> wrote:

In the envelope typ is a media/mime type.  Registering ap= plication/idt+jwt if we register jwt as a structured name sufix.  

Using the cty is also possibl= e.   I need to think about what is better but we can agree on a convent= ion.

Not everything is going to be a set token like not every JWS is a JWT.

If we are going to d= efine processing rules to stop collisions and confusion around JWT for diffe= rent purposes, we should just start using the typ parameter based on the exi= sting spec.

In gen= eral content sniffing if there is more than one option eventually gets you i= nto trouble.

I am n= ot convinced that forcing there to be no sub at the top level is a good idea= .  

It is not= the way we should differentiate between SET and id_tokens.

If sub is not allowed at t= he top level people will do non SET JWT for things where the subject is scop= ed to the iss of the token.

I think defining sub to be part of the event for cases where the s= ub is scoped differently from the issuer of the token is fine, but should no= t be required for all event types.

I think we should solve the confusion issue separately from= the sub issue.

So= rry I am at CIS so trying to catch up on lists.

John B.

On Jun 17, 2017, at 3= :45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

=20 =20

So to s= ummarize what I'm seeing on this thread:

Everybody agrees w= ith Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if w= e do add a "usage" claim, we need to also use it in the SET document before it is published.

Thanks,

    Yaron


On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well.

 =E2=80=94 Justin

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

+1 to what Annabelle said.

Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1

Phil

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna= @amazon.com> wrote:

Mike,

 

Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1. &n= bsp;     The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2. &n= bsp;     Any future ID Token distribution method needs to solve this problem again.

3.      No other profile of JWT can ever use the "nonce=E2=80=9D claim.

4.      This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

 

We know from experience that naming collisions and replay attacks are both things that happen. What=E2=80=99s being proposed is a simpl= e, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80= =9D JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.

&nbs= p;

--&nb= sp;

Annabelle Richard Backman

Identi= ty Services

 
 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscur= tescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

You=E2=80=99ve heard of =E2=80= =9Cpremature optimization=E2=80=9D.  I=E2=80=99d= characterize the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2= =80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.

 

Mand= atory solutions are being proposed in this thread to problems that there=E2=80=99s no evidenc= e that we actually even have.  It=E2=80= =99s already been established that it=E2=80=99= s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.<= /p>

 

The pro= posed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9C= sub=E2=80=9D in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser. = The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key to adoption.  Standards are= only useful if they are actually used.

 

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

 = ;

<= b class=3D"">From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richa= rd Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
= To: Marius Scurtescu <msc= urtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-e= vent@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?

=  

To your= first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.

 

--&nb= sp;

Annabelle Richard Backman

Identi= ty Services

 
 

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.= birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-eve= nt@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

O= n Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?

 =

"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)

 =

"scope" is not used by SET.

 =

I don't know what do you mean by "intend" (or intent)?

 =
 =



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee= that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a =E2=80=9Cfail on= an unrecognized claim=E2=80=9D appr= oach to ensure that JWTs from some future spec can=E2=80=99t b= e mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expec= t implementers to adhere to the =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D= rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.
=
=C2=B7Ditto for =E2=80=9Caud=E2=80= =9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D o= r =E2=80=9Cusage=E2=80=9D claim/header parameter.

--

Annabelle Richard Backman

Identity Services
=
*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov= @matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com <mailto:ms= curtescu@google.com>> wrote:

    Thanks for the poi= nter Dick, very good timing :-)

    The issue is descr= ibed by "2.7. Cross-JWT Confusion" and the
    mitigation is in "= 3.9. Use Mutually Exclusive Validation Rules for
    Different Kinds of= JWTs", specifically "Use different sets of
=     required claims...= ", "Use different keys for different kinds of
    JWTs." and "Use different issuers for different kinds of JWTs.".

    I still think that= a "type" claim would bring a lot of clarity and
    safety.


    Marius

    On Thu, Jun 8, 201= 7 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaro= n, Mike and I just published an BCP ID for JWT
        h= ttp://self-issued.info/?p=3D1690

        On T= hu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
        <= mailto:adawes@google.com>> wrote:

        &nbs= p;   I was initially a fan of keeping SETS to be very similar to
        &nbs= p;   id tokens but I now think this is a better plan.

        &nbs= p;   On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp=
        &nbs= p;   <mailto:nov@matake.jp>> wrote:

        &nbs= p;       +1 especially for "type"

        &nbs= p;       2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
        &nbs= p;       <phil.hunt@oracle.com <mailto:phi= l.hunt@oracle.com>>:

        &nbs= p;           +1

        &nbs= p;           Phil


        &nbs= p;            > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
        &nbs= p;           <mscurtescu@goog= le.com

              &= nbsp;     <mailto:mscurtescu@google.com>> wrote:
        &= nbsp;            >
        &= nbsp;            > There were a couple of proposals on how to
        &= nbsp;           distinguish SETs from Id Tokens and Access Tokens in
        &= nbsp;           such a way that naive implementations will not
        &= nbsp;           confuse one for the other and open up security
        &= nbsp;           vulnerabilities.
        &= nbsp;            >
        &= nbsp;            > There is also another important requirement: the
        &= nbsp;           SET issuer in some cases must be different from the
        &= nbsp;           "sub" issuer. This is the case of an RP sending SETs
        &= nbsp;           to an IdP.
        &= nbsp;            >
        &= nbsp;            > With these requirements in mind I propose the
        &= nbsp;           following:
        &= nbsp;            > - both "sub" and "iss" to be defined at the event
        &= nbsp;           level
        &= nbsp;            > - "iss" at event level and at top SET level can
        &= nbsp;           be different
        &= nbsp;            > - "iss" and "sub"= at event level can be different
        &= nbsp;           across events in the same SET
        &= nbsp;            > - "sub" should NO= T be present at the top SET
        &= nbsp;           level (this solves the disambiguation), please note
        &= nbsp;           "should" and not "must"
        &= nbsp;            >
        &= nbsp;            > This solution als= o allows different profiles that
=         &= nbsp;           define event types to define additional claims
        &= nbsp;           related to sub (like email or phone_number) and
        &= nbsp;           since all these claims will be at the event level
        &= nbsp;           there will be no collisions or ambiguity.
        &= nbsp;            >
        &= nbsp;            > Another proposal (which I supported) was to
        &= nbsp;           define a composite "aud" claim. This is not solving
        &= nbsp;           the requirement for a distinct  SET issuer. Also,
        &= nbsp;           having the same claim name having different syntax
        &= nbsp;           in different token types could lead to confusion.
        &= nbsp;            >
        &= nbsp;            > And yet another proposal was to introduce a new
        &= nbsp;           claim for JWTs that defines a "type". This is not
        &= nbsp;           practical in the short term, and it also is not
        &= nbsp;           solving the distinct issuer requirement, but I think
        &= nbsp;           this is something the JWT group should seriously
        &= nbsp;           consider.
        &= nbsp;            >
        &= nbsp;            > Thoughts?
        &= nbsp;            >
        &= nbsp;            > Marius

        &= nbsp;            > ____________________________= ___________________
        &= nbsp;            > Id-event mailing list

          &nbs= p;          > Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
        &nbs= p;            >
        &nbs= p;           https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.<= wbr class=3D"">ietf.org_mailman_listinfo_id-2Devent&d=3D= DwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXo= Vpn88YKOCd0mxPQFJLhxWI&e=3D

        &nbs= p;           _______________________________________________
        &nbs= p;           Id-event mailing list
        &nbs= p;           Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
        &nbs= p;           https://www.ietf.org/mailman/listinfo/id-event

        &nbs= p;       _______________________________________________
        &nbs= p;       Id-event mailing list
        &nbs= p;       Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
        &nbs= p;       https://www.ietf.org/mailman/listinfo/id-event

        &nbs= p;   --
        &nbs= p;   Adam Dawes | Sr. Product Manager |= adawes@google.com
        &nbs= p;   <mailto:adawes@google.com> |+1 650-214-2410
        &nbs= p;   <tel:(650)%20214-2410>

        &nbs= p;   _______________________________________________
        &nbs= p;   Id-event mailing list
        &nbs= p;   Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
        &nbs= p;   https://www.ietf.org/mailman/listinfo/id-event

        -- <= br class=3D"">         Subs= cribe to the HARDTWARE <http://hardtware.com/> mail list to
        lear= n about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
https://www.ietf.org= /mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.o= rg
https://www.ietf= .org/mailman/listinfo/id-event

 
_____________= __________________________________
Id-event mailing list<= br class=3D""> Id-event@ietf.= org
https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D= JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&= amp;m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zR= oai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D

_______________________________________________
= Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= /a>



____________________________________________=
___
Id-event mailing list
Id-e=
vent@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event maili= ng list
Id-eve= nt@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail-57E11D16-9513-4881-8DD3-1B1D8AEC42B0-- From nobody Wed Jun 21 14:13:14 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3D81289B0 for ; Wed, 21 Jun 2017 14:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfH4QzGZ5tH3 for ; Wed, 21 Jun 2017 14:13:08 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4573A129410 for ; Wed, 21 Jun 2017 14:13:08 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5LLD174020464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 21:13:02 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5LLD04d006596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 21:13:01 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5LLCxMu008091; Wed, 21 Jun 2017 21:12:59 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jun 2017 14:12:58 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-26D6E8F3-8E40-4EDD-BF22-8B061F88C3F6 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> Date: Wed, 21 Jun 2017 14:12:55 -0700 Cc: Annabelle Richard , Henk Birkholz , Justin Richer , Marius Scurtescu , Yaron Sheffer , Michael Jones , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39! @mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> To: John Bradley X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:13:13 -0000 --Apple-Mail-26D6E8F3-8E40-4EDD-BF22-8B061F88C3F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Separate or combined may be evolving. Mike wants to keep the current backcha= nnel logout very narrowly scoped. He suggested risc define its own duplicate= definitions and meanings.=20 That leads me to believe we will have multi-type events in practice. Session cancellation can occur for many reasons. One of the differentiators w= e had tried to make was an assumption that user initiated events would be pa= rt of connect. Risk would cover variations that drive off of risk calculatio= ns like password reset.=20 There are also signout events at rp's to let the OP know. These are not comm= ands but notification that a resource session is cancelled. IOW single sign o= ut not expected.=20 Phil > On Jun 21, 2017, at 1:58 PM, John Bradley wrote: >=20 > I thought we decided that we are only allowing set messages form the same f= amily that agree on top level claims. >=20 > Otherwise there can be no top level claims and we are really defining a al= ternative format to JWT in some ways. >=20 > John B. >=20 >> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle wrote: >>=20 >> I agree with John that the JWT type confusion problem and the SET sub pro= blem can and should be discussed separately. The secevents WG is probably no= t the right setting to discuss the former. >> =20 >> My concern with the sub claim is that two profiles may dictate conflictin= g semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B says= it=E2=80=99s an email address). If these profiles don=E2=80=99t provide an a= lternate way to declare subject of their events, then they cannot be present= within the same token. This incompatibility trap seems like something that c= ould be easily missed by groups profiling SET. >> =20 >> --=20 >> Annabelle Richard Backman >> Identity Services >> =20 >> =20 >> From: John Bradley >> Date: Wednesday, June 21, 2017 at 1:39 PM >> To: Yaron Sheffer >> Cc: Justin Richer , Marius Scurtescu , Annabelle Richard , Phil Hunt , Michael Jones , ID Events Mailing List , Henk Birkholz >> Subject: Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer >> =20 >> In the envelope typ is a media/mime type. Registering application/idt+jw= t if we register jwt as a structured name sufix. =20 >> =20 >> Using the cty is also possible. I need to think about what is better bu= t we can agree on a convention. >> =20 >> Not everything is going to be a set token like not every JWS is a JWT. >> =20 >> If we are going to define processing rules to stop collisions and confusi= on around JWT for different purposes, we should just start using the typ par= ameter based on the existing spec. >> =20 >> In general content sniffing if there is more than one option eventually g= ets you into trouble. >> =20 >> I am not convinced that forcing there to be no sub at the top level is a g= ood idea. =20 >> =20 >> It is not the way we should differentiate between SET and id_tokens. >> =20 >> If sub is not allowed at the top level people will do non SET JWT for thi= ngs where the subject is scoped to the iss of the token. >> =20 >> I think defining sub to be part of the event for cases where the sub is s= coped differently from the issuer of the token is fine, but should not be re= quired for all event types. >> =20 >> I think we should solve the confusion issue separately from the sub issue= . >> =20 >> Sorry I am at CIS so trying to catch up on lists. >> =20 >> John B. >> =20 >>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote= : >>> =20 >>> So to summarize what I'm seeing on this thread: >>> Everybody agrees with Marius's short-term solution, specific rules for "= sub" and "iss" that can be defined in the SET spec. >>> Almost everybody agrees on a long-term "usage" claim ("type" is taken) t= hat should be defined elsewhere, e.g. in the JWT BCP. >>> Did I miss anything? >>> By the way, if we do add a "usage" claim, we need to also use it in the S= ET document before it is published. >>> Thanks, >>> Yaron >>> =20 >>>> On 15/06/17 22:08, Justin Richer wrote: >>>> +1 to this as well.=20 >>>> =20 >>>> =E2=80=94 Justin >>>> =20 >>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu w= rote: >>>>> =20 >>>>> +1 to what Annabelle said.=20 >>>>> =20 >>>>> Also, Mike you are missing the other requirement, for RPs to send even= ts to an IdP. The iss+sub pair at the top level is broken in this case. >>>>>=20 >>>>> Marius >>>>> =20 >>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wrote: >>>>>> +1 >>>>>> =20 >>>>>> Phil >>>>>>=20 >>>>>>=20 >>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >>>>>>> Mike, >>>>>>> =20 >>>>>>> Your explanation for why this is a non-problem is dependent upon sid= e effects of elements of OpenID Connect that were not designed to solve this= issue. As a result, I see several issues with it: >>>>>>> 1. The caller of the Token Endpoint is the only party that can= be certain that a nonce-less ID Token is really an ID Token. Any party that= the caller passes the ID Token off to has no way to verify its provenance. >>>>>>>=20 >>>>>>> 2. Any future ID Token distribution method needs to solve this= problem again. >>>>>>>=20 >>>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D cla= im. >>>>>>>=20 >>>>>>> 4. This is only a solution for ID Tokens. Every other JWT profi= le that cares about disambiguation has to invent its own solution to the pro= blem. >>>>>>>=20 >>>>>>> =20 >>>>>>> We know from experience that naming collisions and replay attacks ar= e both things that happen. What=E2=80=99s being proposed is a simple, defens= ive measure against these risks. You brought up JWT libraries: a general sol= ution actually makes it easier to use common libraries for JWT parsing. A =E2= =80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for any J= WT profile, whereas with the status quo each profile would require unique lo= gic. >>>>>>> =20 >>>>>>> --=20 >>>>>>> Annabelle Richard Backman >>>>>>> Identity Services >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Id-event on behalf of Mike Jones <= Michael.Jones@microsoft.com> >>>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>>> To: Marius Scurtescu >>>>>>> Cc: "Richard Backman, Annabelle" , ID Events Ma= iling List , Henk Birkholz >>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer >>>>>>> =20 >>>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I= =E2=80=99d characterize the proposals in this thread as =E2=80=9Cpremature p= essimation=E2=80=9D =E2=80=93 making things that can and should be simple co= mplex, without data showing there=E2=80=99s any need to do so. >>>>>>> =20 >>>>>>> Mandatory solutions are being proposed in this thread to problems th= at there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been established that it=E2=80=99s impossible for a SET to be confused f= or an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/= current/msg00428.html. If people have data showing that this is possible wi= th specific kinds of Access Tokens or other real JWT deployments, please pro= vide specifics, so that we can use that data to inform appropriate engineeri= ng choices on our part. >>>>>>> =20 >>>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the us= e of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, wou= ld make previously simple things unnecessarily complex. Yes, then the resul= t is then different than a normal JWT but a consequence of this is that cust= om parsing code would have to be used, rather than a standard JWT parser. T= he more unwieldy we make it to use SETs, the more likely developers are to j= ust create their own data structures. Keeping it simple is the key to adopt= ion. Standards are only useful if they are actually used. >>>>>>> =20 >>>>>>> -- Mike >>>>>>> =20 >>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richa= rd Backman, Annabelle >>>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>>> To: Marius Scurtescu ; Henk Birkholz >>>>>>> Cc: ID Events Mailing List >>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer >>>>>>> =20 >>>>>>> Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? >>>>>>> =20 >>>>>>> To your first question, I think a better analogy would be the X.509 K= ey Usage extension: a multi-valued property that declares the intended purpo= se of the JWT, and that a recipient may refer to when determining whether to= accept a JWT being presented to it in some context. >>>>>>> =20 >>>>>>> --=20 >>>>>>> Annabelle Richard Backman >>>>>>> Identity Services >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Id-event on behalf of Marius Scurt= escu >>>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>>> To: Henk Birkholz >>>>>>> Cc: ID Events Mailing List >>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer >>>>>>> =20 >>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: >>>>>>>> And a 2nd question. >>>>>>>>=20 >>>>>>>> What semantics would "usage" provide that that are not covered via "= intend", "audience", and "scope"? >>>>>>> =20 >>>>>>> "aud" (audience) specifies the target client, but not the intended u= sage (access token to authorize resource access or SET to communicate a secu= rity event?) >>>>>>> =20 >>>>>>> "scope" is not used by SET. >>>>>>> =20 >>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>> =20 >>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Henk >>>>>>>>=20 >>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>> Thanks for putting this together! >>>>>>>>>=20 >>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>=20 >>>>>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a= mutually exclusive set of valid claims and/or header parameters, and enforc= ing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach= to ensure that JWTs from some future spec can=E2=80=99t be mistaken for JWT= s from a current spec. >>>>>>>>>=20 >>>>>>>>> =C2=B7It is unrealistic to expect implementers to adhere to the =E2= =80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. Whether mand= ated by the spec or not, implementers will ignore this because managing one k= ey is easier than managing N different keys. >>>>>>>>>=20 >>>>>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D cl= aims. >>>>>>>>>=20 >>>>>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/h= eader parameter. >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>>=20 >>>>>>>>> Annabelle Richard Backman >>>>>>>>>=20 >>>>>>>>> Identity Services >>>>>>>>>=20 >>>>>>>>> *From: *Id-event on behalf of Dick Har= dt >>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>> *To: *Marius Scurtescu >>>>>>>>> *Cc: *Adam Dawes , "matake, nov" , ID Events Mailing List , "Phil Hunt (IDM)" >>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion a= nd distinct SET issuer >>>>>>>>>=20 >>>>>>>>> Agreed. Note that there is still lots of discussion on what should= be in 3.9. >>>>>>>>>=20 >>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >>>>>>>>>=20 >>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>=20 >>>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" and the >>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive Validation Rules= for >>>>>>>>> Different Kinds of JWTs", specifically "Use different sets of >>>>>>>>> required claims...", "Use different keys for different kinds o= f >>>>>>>>> JWTs." and "Use different issuers for different kinds of JWTs.= ". >>>>>>>>>=20 >>>>>>>>> I still think that a "type" claim would bring a lot of clarity= and >>>>>>>>> safety. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Marius >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>> http://self-issued.info/?p=3D1690 >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> I was initially a fan of keeping SETS to be very simil= ar to >>>>>>>>> id tokens but I now think this is a better plan. >>>>>>>>>=20 >>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> +1 especially for "type" >>>>>>>>>=20 >>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>> = >: >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtesc= u >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> > >>>>>>>>> > There were a couple of proposals on how to >>>>>>>>> distinguish SETs from Id Tokens and Access Tok= ens in >>>>>>>>> such a way that naive implementations will not= >>>>>>>>> confuse one for the other and open up security= >>>>>>>>> vulnerabilities. >>>>>>>>> > >>>>>>>>> > There is also another important requirement= : the >>>>>>>>> SET issuer in some cases must be different fro= m the >>>>>>>>> "sub" issuer. This is the case of an RP sendin= g SETs >>>>>>>>> to an IdP. >>>>>>>>> > >>>>>>>>> > With these requirements in mind I propose t= he >>>>>>>>> following: >>>>>>>>> > - both "sub" and "iss" to be defined at the= event >>>>>>>>> level >>>>>>>>> > - "iss" at event level and at top SET level= can >>>>>>>>> be different >>>>>>>>> > - "iss" and "sub" at event level can be dif= ferent >>>>>>>>> across events in the same SET >>>>>>>>> > - "sub" should NOT be present at the top SE= T >>>>>>>>> level (this solves the disambiguation), please= note >>>>>>>>> "should" and not "must" >>>>>>>>> > >>>>>>>>> > This solution also allows different profile= s that >>>>>>>>> define event types to define additional claims= >>>>>>>>> related to sub (like email or phone_number) an= d >>>>>>>>> since all these claims will be at the event le= vel >>>>>>>>> there will be no collisions or ambiguity. >>>>>>>>> > >>>>>>>>> > Another proposal (which I supported) was to= >>>>>>>>> define a composite "aud" claim. This is not so= lving >>>>>>>>> the requirement for a distinct SET issuer. Al= so, >>>>>>>>> having the same claim name having different sy= ntax >>>>>>>>> in different token types could lead to confusi= on. >>>>>>>>> > >>>>>>>>> > And yet another proposal was to introduce a= new >>>>>>>>> claim for JWTs that defines a "type". This is n= ot >>>>>>>>> practical in the short term, and it also is no= t >>>>>>>>> solving the distinct issuer requirement, but I= think >>>>>>>>> this is something the JWT group should serious= ly >>>>>>>>> consider. >>>>>>>>> > >>>>>>>>> > Thoughts? >>>>>>>>> > >>>>>>>>> > Marius >>>>>>>>>=20 >>>>>>>>> > ___________________________________________= ____ >>>>>>>>> > Id-event mailing list >>>>>>>>> > Id-event@ietf.org >>>>>>>>> > >>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dh= ttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_l= LIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVq= XoVpn88YKOCd0mxPQFJLhxWI&e=3D >>>>>>>>>=20 >>>>>>>>> ______________________________________________= _ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event= >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Adam Dawes | Sr. Product Manager |adawes@google.com >>>>>>>>> |+1 650-214-2410 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Subscribe to the HARDTWARE mail li= st to >>>>>>>>> learn about projects I am working on! >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>>=20 >>>>>>>>> Subscribe to the HARDTWARE mail list to le= arn about projects I am working on! >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>=20 >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk= KY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHs= hmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D >>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>> =20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 >> =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-26D6E8F3-8E40-4EDD-BF22-8B061F88C3F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Separate or combined may be evolving. M= ike wants to keep the current backchannel logout very narrowly scoped. He su= ggested risc define its own duplicate definitions and meanings. 
<= div id=3D"AppleMailSignature">
That l= eads me to believe we will have multi-type events in practice.

Session cancel= lation can occur for many reasons. One of the differentiators we had tried t= o make was an assumption that user initiated events would be part of connect= . Risk would cover variations that drive off of risk calculations like passw= ord reset. 

There are also signout events at rp's to let the OP know. T= hese are not commands but notification that a resource session is cancelled.= IOW single sign out not expected. 

Phil

On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing s= et messages form the same family that agree on top level claims.

Otherwise there can be no top level c= laims and we are really defining a alternative format to JWT in some ways.

John B.

On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
I agr= ee with John that the JWT type confusion problem and the SET sub problem can= and should be discussed separately. The secevents WG is probably not the ri= ght setting to discuss the former.
 
My concern with the sub claim is that two profiles= may dictate conflicting semantics (e.g. Profile A says it=E2=80=99s a phone= number, Profile B says it=E2=80=99s an email address). If these profiles do= n=E2=80=99t provide an alternate way to declare subject of their events, the= n they cannot be present within the same token. This incompatibility trap se= ems like something that could be easily missed by groups profiling SET.
 
= -- 
Annabelle= Richard Backman
= Identity Services
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Wednesday,= June 21, 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin= Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>,= Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkhol= z <henk.bir= kholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for I= d/Access Token confusion and distinct SET issuer
 
In the envelope typ i= s a media/mime type.  Registering application/idt+jwt if we register jw= t as a structured name sufix.  
 
<= div class=3D"">
Using the cty is also possibl= e.   I need to think about what is better but we can agree on a convent= ion.
 
Not everything is going to be a set tok= en like not every JWS is a JWT.
 
<= div class=3D"">
If we are going to define pro= cessing rules to stop collisions and confusion around JWT for different purp= oses, we should just start using the typ parameter based on the existing spe= c.
 
In general content sniffing if there is more than one opti= on eventually gets you into trouble.
 
=
I am not convinced tha= t forcing there to be no sub at the top level is a good idea.  
 
It is not the way we should differentiate between SET and id_tokens= .
 
If sub is not allowed at the top level people will do non SET J= WT for things where the subject is scoped to the iss of the token.
 
I think defining sub to be part of the event for cases where the sub= is scoped differently from the issuer of the token is fine, but should not b= e required for all event types.
 
<= div class=3D"">
I think we should solve the c= onfusion issue separately from the sub issue.
 
Sorry I am at C= IS so trying to catch up on lists.
 
John B.<= /o:p>
 
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:<= /div>
 
So to summa= rize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specif= ic rules for "sub" and "iss" that can be defined in the SET spec.
Almost everybody agrees on a l= ong-term "usage" claim ("type" is taken) that should be defined elsewhere, e= .g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it in t= he SET document before it is published.
Thanks,
    Yaron
On 15/06/17 22:08, Justin Richer wrote:
+1 to this a= s well. 
&n= bsp;
 = =E2=80=94 Justin
On Jun 15, 2017, at 1:09= PM, Marius Scurtescu <mscurtescu@google.com= > wrote:
 
+1 to what Annabelle said. 
 
Also, Mike you are missing the other re= quirement, for RPs to send events to an IdP. The iss+sub pair at the top lev= el is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
 
Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= o:p class=3D"">

Mike,
 
Your explanation for why t= his is a non-problem is dependent upon side effects of elements of OpenID Co= nnect that were not designed to solve this issue. As a result, I see several= issues with it:

1.       The caller of the Token End= point is the only party that can be certain that a nonce-less ID Token is re= ally an ID Token. Any party that the caller passes the ID Token off to has n= o way to verify its provenance.

2.=      &nb= sp; Any future ID= Token distribution method needs to solve this problem again.

3.   &nb= sp;  No othe= r profile of JWT can ever use the "nonce=E2=80=9D claim.

4= .    &= nbsp; This is only= a solution for ID Tokens. Every other JWT profile that cares about disambig= uation has to invent its own solution to the problem.=

 
We know from= experience that naming collisions and replay attacks are both things that h= appen. What=E2=80=99s being proposed is a simple, defensive measure against t= hese risks. You brought up JWT libraries: a general solution actually makes i= t easier to use common libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80= =9D JWT library could handle disambiguation for any JWT profile, whereas wit= h the status quo each profile would require unique logic.
 
-- 
A= nnabelle Richard Backman
Identity Services
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times N= ew Roman', serif;" class=3D""> 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>= ;
Date:&nb= sp;Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu= <mscurtescu@google.com>
Cc:&= nbsp;"Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Bir= kholz <henk.birk= holz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id= /Access Token confusion and distinct SET issuer=
=  
You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D.&n= bsp; I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprema= ture pessimation=E2=80=9D =E2=80=93 making things that can and should be sim= ple complex, without data showing there=E2=80=99s any need to do so.<= o:p class=3D"">
<= span style=3D"font-family: Calibri, sans-serif; color: rgb(0, 32, 96);" clas= s=3D""> 
Mandatory solutions are being proposed in this thread to pro= blems that there=E2=80=99s no evidence that we actually even have.  It=E2= =80=99s already been established that it=E2=80=99s impossible for a SET to b= e confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.=   If people have data showing that this is possible with specific kinds= of Access Tokens or other real JWT deployments, please provide specifics, s= o that we can use that data to inform appropriate engineering choices on our= part.
 
The proposed =E2=80=9Csolutions=E2=80=9D, suc= h as prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, or requ= iring a type claim, would make previously simple things unnecessarily comple= x.  Yes, then the result is then different than a normal JWT but a cons= equence of this is that custom parsing code would have to be used, rather th= an a standard JWT parser.  The more unwieldy we make it to use SETs, th= e more likely developers are to just create their own data structures. = Keeping it simple is the key to adoption.  Standards are only useful i= f they are actually used.
=
 <= /div>
    &= nbsp;            = ;            &nb= sp;            &= nbsp;     -- Mike
 
<= b class=3D"">From: = Id-event [mailto:i= d-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 P= M
To:&= nbsp;Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: <= /span>ID Events Mailing List <= id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Acce= ss Token confusion and distinct SET issuer
 
Echoing Marius=E2=80= =99s question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?
 
To your first question, I think a better analogy would be the X.509 Key U= sage extension: a multi-valued property that declares the intended purpose o= f the JWT, and that a recipient may refer to when determining whether to acc= ept a JWT being presented to it in some context.
 
= -- 
Annabelle= Richard Backman
= Identity Services
 
 
From: Id-event <id-= event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de= >
Cc: ID Events Mailing List <id-event@ietf.org>
Subject:<= span class=3D"Apple-converted-space"> Re: [Id-event] solutio= n for Id/Access Token confusion and distinct SET issuer
 
On Tue, Jun 13, 20= 17 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:=
And a 2nd question.

What semanti= cs would "usage" provide that that are not covered via "intend", "audience",= and "scope"?
 
=
"aud" (audience)= specifies the target client, but not the intended usage (access token to au= thorize resource access or SET to communicate a security event?)
 
"scope" is not used by SET.<= /div>
&= nbsp;
I don't know what do you mean by "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a m= utually exclusive set of valid claims and/or header parameters, and enforcin= g this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach t= o ensure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs f= rom a current spec.

=C2=B7It is unrealistic to e= xpect implementers to adhere to the =E2=80=9Cdifferent keys for different ki= nds of JWTs=E2=80=9D rule. Whether mandated by the spec or not, implementers= will ignore this because managing one key is easier than managing N differe= nt keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D a= nd =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80= =9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header parameter.

-- 
Annabelle Richard Backman

Identity Services

*From: *Id-event <<= a href=3D"mailto:id-event-bounces@ietf.org" target=3D"_blank" style=3D"color= : purple; text-decoration: underline;" class=3D"">id-event-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 a= t 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam= Dawes <adawes@google.com&= gt;, "matake, nov" <nov@matake.jp<= /a>>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *= Re: [Id-event] solution for Id/Access Token confusion and distinct SET issue= r

Agreed. Note that there is still lots of disc= ussion on what should be in 3.9.

On Mon, Jun 12= , 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)
    The issue is described by "2.7. Cro= ss-JWT Confusion" and the
    mitigation is in "3.9.= Use Mutually Exclusive Validation Rules for
    Dif= ferent Kinds of JWTs", specifically "Use different sets of
&nb= sp;   required claims...", "Use different keys for different kinds of    JWTs." and "Use different issuers for different k= inds of JWTs.".

    I still think tha= t a "type" claim would bring a lot of clarity and
   = ; safety.


    Marius
    On Thu, Jun 8, 2017 at 9:59 PM, Di= ck Hardt <dick.hardt@gmail.= com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BC= P ID for JWT
        http://self-issu= ed.info/?p=3D1690

      &nbs= p; On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
      &nb= sp; <mailto:adawes@google.com>> wrote:

        &n= bsp;   I was initially a fan of keeping SETS to be very similar to
            id tokens but I now thin= k this is a better plan.

      &= nbsp;     On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
    &= nbsp;       <mailto:nov@matake.jp>> wrote:

   =             +1 especially for "type"

               = 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
    &nbs= p;           <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

                    +1<= br class=3D"">
             = ;       Phil


&nbs= p;                    >= On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
    &n= bsp;               <mscurtescu@google.com=
 =                   <mailto:<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" style=3D"color: pu= rple; text-decoration: underline;" class=3D"">mscurtescu@google.com>&= gt; wrote:
              &n= bsp;      >
        &nbs= p;            > There were a couple of prop= osals on how to
            &nbs= p;       distinguish SETs from Id Tokens and Access Tokens in=
                 = ;   such a way that naive implementations will not
 =                   confuse one f= or the other and open up security
        &= nbsp;           vulnerabilities.
&nbs= p;                    >=
                 = ;    > There is also another important requirement: the
                   = SET issuer in some cases must be different from the
  &n= bsp;                 "sub" issuer. T= his is the case of an RP sending SETs
      &nb= sp;             to an IdP.
 = ;                    ><= br class=3D"">                 =    > With these requirements in mind I propose the
                    fol= lowing:
               = ;      > - both "sub" and "iss" to be defined at the event=
                 = ;   level
             = ;        > - "iss" at event level and at top SET leve= l can
                &= nbsp;   be different
          &= nbsp;          > - "iss" and "sub" at event leve= l can be different
            &= nbsp;       across events in the same SET
 = ;                    > -= "sub" should NOT be present at the top SET
    &nbs= p;               level (this solves the d= isambiguation), please note
         =           "should" and not "must"
&n= bsp;                    &g= t;
                &nb= sp;    > This solution also allows different profiles that
                  &nb= sp; define event types to define additional claims
  &nbs= p;                 related to sub (l= ike email or phone_number) and
        &nb= sp;           since all these claims will be at the= event level
              &= nbsp;     there will be no collisions or ambiguity.
=                      = >
                &= nbsp;    > Another proposal (which I supported) was to
                    d= efine a composite "aud" claim. This is not solving
  &nbs= p;                 the requirement f= or a distinct  SET issuer. Also,
      &nb= sp;             having the same claim name hav= ing different syntax
           =         in different token types could lead to confusio= n.
                &nb= sp;    >
           = ;          > And yet another proposal was to int= roduce a new
              &= nbsp;     claim for JWTs that defines a "type". This is not
                   = ; practical in the short term, and it also is not
   = ;                 solving the distin= ct issuer requirement, but I think
       =             this is something the JWT group s= hould seriously
            &nbs= p;       consider.
        &= nbsp;            >
  &nb= sp;                  > Thoug= hts?
                &= nbsp;    >
          &nb= sp;          > Marius

                    &nb= sp;> _______________________________________________
 =                    > I= d-event mailing list

                &= nbsp;    > Id-event@ietf.org <mailto:Id-event@ietf.org>
      &= nbsp;              >
&nb= sp;                   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBK= CX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn= 88YKOCd0mxPQFJLhxWI&e=3D

    &= nbsp;               _____________________= __________________________
          &= nbsp;         Id-event mailing list
 =                   Id-event@ietf.org &= lt;mailto:Id-event@ietf.org&g= t;
                &nb= sp;   https://www.ietf.org/mailman/listinfo/id-event

            &nb= sp;   _______________________________________________
&nb= sp;               Id-event mailing list                Id-event@ietf.org <= /span><mailto:Id-event@ietf.or= g>
              &nb= sp; https://www.ietf.org/mailman/listinfo/id-event

            -- 
    &nbs= p;       Adam Dawes | Sr. Product Manager |adawes@google.com
    &= nbsp;       <mailto:adawes@google.com> |+1 6= 50-214-2410
            <= tel:(650)%20214-2410>

            _________= ______________________________________
      &n= bsp;     Id-event mailing list
      &= nbsp;     Id-event@ietf.org <mailto:Id-event@ietf.org>
       = ;     https://www.ietf.org/mailman/listinfo/id-eve= nt

        -- 
     =   Subscribe to the HARDTWARE <http://hardtware.com/<= /a>> mail list to
        learn about p= rojects I am working on!



-- 
=
Subscribe to the HARDTWARE <http://hardtware= .com/> mail list to learn about projects I am working on!



____________________________= ___________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id= -event


__________________________= _____________________
Id-event mailing list
Id-event@ietf.org
<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or= g_mailman_listinfo_id-2Devent&d=3DDwMGaQ&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&= ;m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9u= gLD4EKb9uyg7oMU7TmGMSWWs&e=3D" target=3D"_blank" style=3D"color: purple;= text-decoration: underline;" class=3D"">https://www.ietf.org/mailman/listin= fo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf= .org
https:= //www.ietf.org/mailman/listinfo/id-event
 <= /o:p>



___=
____________________________________________
Id-event mailing listId-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_____________= __________________________________
Id-event mailing list
Id-event@ietf.org
https://www.= ietf.org/mailman/listinfo/id-event
 <= /div>

<= /div>
_____________________= __________________________
Id-event mailing list
<= span>Id-event@ietf.org
https://www.i= etf.org/mailman/listinfo/id-event
= --Apple-Mail-26D6E8F3-8E40-4EDD-BF22-8B061F88C3F6-- From nobody Wed Jun 21 14:20:06 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464D2128B4E for ; Wed, 21 Jun 2017 14:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDcnSrB3VagD for ; Wed, 21 Jun 2017 14:19:59 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5C21289B0 for ; Wed, 21 Jun 2017 14:19:58 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id t87so11617772ioe.0 for ; Wed, 21 Jun 2017 14:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kdjqdot2DIb3b0buMvGBVwA3ZOm/H7I4A1PI3SNipcc=; b=HXi/D96p14C4+lvmw7Ju9YwG5gx/qJQvqSEJJpIk2HPgicNG3kvV4TsZk4fGm6J2Wt DuRtPNhK4IkOYK+7sGtx8j9xtOhmsAdPr85W5UyTDU8FR7ljxnKL/S2JSYytISoBy1Hn eNvpcWJvOOffge+P4V0QbJoeLoxw+77z0SO2rgvYOpTf2Ptfv0FAXGF9SZodwNEbbZ/c 3ZDhzw8W4wuROsMMkSTNOvSl5wIWZEz3zZTMjdlm9m6MrRhQTNbITQqm/mTDu+DvUqMO igTS4XdTydQIfobLTr7HrGAgYxEYM+tD3PoAcinje2RYlkQpXdekDgTr9cLj1sHAptCF KjhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kdjqdot2DIb3b0buMvGBVwA3ZOm/H7I4A1PI3SNipcc=; b=hYNLGOnpyZ+hb/NW51N5CFyMKgEUHuM6Goam7a9qluE3zS6Dy5hmPnyAjoWvRAcJJf 7QGfLcq0pHP1ze8SN9meOPLat+lZXxTH9yOdWHfGMs8jHI7b/5AsiLiVtegBjnx12l8t hs9C05mB2wbYdayofAqO8Jr06auV04oQxsfEsR+xHMLCdx6P6E1qegwJB0YJ1bV7XpRR CDfSqt8PloyZetVdNBok6WdvARWc7Kq7Fkbc7gUgjk9wFZ0a0ZP8I2wadf3x9TiA7uW3 7BKYGdThAQLShVj0A5dLPfvZWtXcVAACqurtS8LnI5xiNo62XTiitUmGyuk1QVbA7gu8 qTVw== X-Gm-Message-State: AKS2vOxvwcRZ8K/IDDItdY3UQ+h6IPkvr/ARfC08dx3txNYhXj2TZBKZ vLpj0oRcWYNjIcjyMujWuFPA++HptpIJ X-Received: by 10.107.18.16 with SMTP id a16mr33949253ioj.93.1498079997676; Wed, 21 Jun 2017 14:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Wed, 21 Jun 2017 14:19:36 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> From: Marius Scurtescu Date: Wed, 21 Jun 2017 14:19:36 -0700 Message-ID: To: Mike Jones Cc: "M.Lizar@OCG" , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="001a113ee31e1bb45f05527eeebb" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:20:05 -0000 --001a113ee31e1bb45f05527eeebb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2017 at 1:19 PM, Mike Jones wrote: > Marius, the question =E2=80=9CDo you have examples of use cases that cann= ot > handle sub at the event level?=E2=80=9D is no more useful than the questi= on =E2=80=9CDo > you have examples of use cases that cannot handle =E2=80=98sub=E2=80=99 s= pelled as the > Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D > I disagree. If sub at the event level is an issue then let's be concrete about it. > Yes, applications could always work around the inconveniences introduce= d > by arbitrary claim renaming or repositioning, > This is not an arbitrary repositioning, the reasons a very clear. but they shouldn=E2=80=99t have to. It just adds complexity and will hinde= r > adoption. > Minor complexity added, if at all. The only downside is the slightly larger size of SETs. > > > It seems to me that your motivation for always having =E2=80=9Csub=E2=80= =9D in the event > payload, rather than a normal claim, is that that=E2=80=99s how you think= RISC > events will be structured, and that you want **all** events to also use > the RISC event structuring. > This has absolutely nothing to do with RISC in particular. Both the confusion problem and the RP issued SETs are generic SET problems that need to be solved. BTW, you never offered a solution to the RP issued SETs problem MIke. Can you please do that? > To my way of thinking, if you really believe that you should be asking > the SET spec to be withdrawn from the IETF and only define RISC events in > the RISC working group. But in fact, requiring all events to follow the > RISC conventions makes no more sense than requiring all JWTs to be ID > Tokens. That would have made JWTs useless for many use cases. Proposing > to limit claims usage in SETs would likewise make them inapplicable for > many non-RISC use cases. > > > > We have a potential success on our hands. Let=E2=80=99s not screw it up = by making > it unnecessarily complicated. > Sure, let's solve all open issues first. > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Wednesday, June 21, 2017 1:53 PM > *To:* M.Lizar@OCG > *Cc:* Mike Jones ; Richard Backman, > Annabelle ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>; Justin Richer ; Yaron > Sheffer ; ID Events Mailing List ; > Phil Hunt > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG < > m.lizar@openconsentgroup.com> wrote: > > FWIW - I agree with Mike that putting restrictions on the "sub" claim > usage would unnecessarily complicate SETs for some use cases. > > > > sub is defined as optional in JWT, so technically we are not adding any > restrictions. Do you have examples of use cases that cannot handle sub at > the event level? > > > > > > > > Its a lot easier to add to a spec and very difficult (if not impossible) > to retract. > > > > I agree. I don't think anything is retracted. > > > > Again, see: > > https://tools.ietf.org/html/rfc7519#section-4.1.2 > > > > Last sentence of 4.1.2 states "Use of this claim is OPTIONAL." > > > > > > In this regard, keeping it simple is critical for broad adoption. > > > > Mark > > > > On 19 Jun 2017, at 16:55, Marius Scurtescu wrote: > > > > Mike, are you suggesting we define SETs in such a way that they will not > work for RISC? A top level iss+sub is clearly not working for RISC, and m= ay > not work for logout either if you allow logout to be initiated from an RP= . > > > Marius > > > > On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones > wrote: > > Marius, there=E2=80=99s nothing stopping you (or the RISC working group o= r other > profiles) from defining events that can be sent from RPs to IdPs now, > without any changes to the SET spec. Specify the claims you want to use, > and you=E2=80=99re golden. > > > > But it would be counterproductive to require all other SETs to meet the > requirements of your specific profile. There are simpler use cases that > can use claims in simpler ways. Trying to make the simple use cases be > complex will have the side effect of limiting the adoption of the spec, > which wouldn=E2=80=99t be good for anyone. > > > > If successful, SETs will have many different profiles. That=E2=80=99s a = sign of > success =E2=80=93 not a sign of weakness. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Monday, June 19, 2017 11:58 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Justin Richer < > jricher@mit.edu>; Richard Backman, Annabelle ; Henk > Birkholz ; ID Events Mailing List < > id-event@ietf.org>; Phil Hunt > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > > > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones > wrote: > > I=E2=80=99m sorry to be slow replying to some messages in this thread. I= have a > lot of other things on my plate, but I will take the time now to reply, > because I wholeheartedly disagree with some of the statements below and > believe it would be severely harmful to the specification and its adoptio= n > to act upon them. Specifically: > > > > - I disagree that specific rules should be made for the =E2=80=9Csub= =E2=80=9D claim. > Claims usage needs to be up to the application. I know that many othe= rs > agree with me, because the OpenID Connect working group designed the l= ogout > token in http://openid.net/specs/openid-connect-backchannel-1_ > 0-04.html#LogoutToken (which is also used as an example in > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 > ) > to use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibiting= this usage would be > a completely unnecessary breaking change =E2=80=93 as it=E2=80=99s imp= ossible to confuse a > logout token with an ID Token, for reasons already cites in this threa= d. > > Solving the confusion is one problem. The other problem I keep mentioning > is SETs issued by an RP to be sent to an IdP. How are we solving that > problem Mike? In this case the top level iss is different from the iss of > the sub, a top level sub is not possible. > > > > And I don't want to downplay the confusion problem either. I think it is = a > real concern and I think a solid solution is important. > > > > The OpenID Working Group designed logout tokens without secevent in mind. > I agree we should not recklessly break compatibility, but to me it seems > necessary in this case. > > > > > - > > > > - (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 > = . > No further =E2=80=9Ciss=E2=80=9D rules are needed.) > > > > Further iss ruies are absolutely needed for the RP to IdP case described > above. > > > > > > > - > > > > - It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to = be used for some > profiles to differentiate between kinds of JWTs. Its use should not b= e > mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D > functionality by defining another claim with a duplicative meaning. > > If typ can be use and no other claim is needed, then let's talk about > that. I do think SET should mandate it. I don't understand why not. Can y= ou > please propose with examples how can typ be used? > > > > > > > - > > > > - I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of > JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D This reflects a = misunderstanding. > It=E2=80=99s the **value** of the nonce that self-secures the JWT =E2= =80=93 not that > any =E2=80=9Cnonce=E2=80=9D claim is present. Any and all JWTs can si= multaneously use > =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a > cryptographically secure random number. > > > > For SETs I cannot see how the nonce value is useful. That value is not > passed back and it cannot be verified. Only the presence of the claim cou= ld > have some use, hinting at the usage of the JWT, a very weak solution to t= he > confusion problem. > > > > > - > > > > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d = be glad > to have in-person discussions about these topics there. > > > > -- Mike > > > > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or= any other claim) > or forcing it to be located in a non-standard location makes about as muc= h > sense as arbitrarily saying that, for a particular profile, the Latin wor= d > for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name in= stead of =E2=80=9Csub=E2=80=9D. > Yes, it will completely differentiate this profile from others not spelli= ng > the claim name this way, but it would certainly be an impediment to the u= se > of standard JWT libraries and to interoperability. > > > > If we define that sub must be at the event level then it is at a standard > location, I don't see what the issue is. The impediment you mention is th= e > actual solution. I don't think that a JWT library that was written for Id > Tokens should be used to parse SETs. The library has to be SET aware, in > which case the event level iss+sub is not an issue at all. > > > > > > > > > > *From:* Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > *Sent:* Saturday, June 17, 2017 1:45 PM > *To:* Justin Richer ; Marius Scurtescu < > mscurtescu@google.com> > *Cc:* Richard Backman, Annabelle ; Mike Jones < > Michael.Jones@microsoft.com>; Henk Birkholz de>; ID Events Mailing List ; Phil Hunt < > phil.hunt@oracle.com> > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id- > 2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > --001a113ee31e1bb45f05527eeebb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 1:19 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Marius, the question = =E2=80=9CDo you have examples of use cases that cannot handle sub at= the event level?=E2=80=9D is no more useful = than the question =E2=80=9CDo you have examples of use cases that cannot handle =E2=80=98sub=E2=80=99 spelled as the Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D


I disagree. If sub at the event = level is an issue then let's be concrete about it.

=
=C2=A0
=C2=A0 Yes, applications= could always work around the inconveniences introduced by arbitrary claim = renaming or repositioning,


This is not an arbitrary repositioning, the reasons a very clear.


but t= hey shouldn=E2=80=99t have to.=C2=A0 It just adds complexity and will hinder adoption.


Minor complexity added, if at all. The only downside is t= he slightly larger size of SETs.
=C2=A0

=C2=A0

It seems to me that yo= ur motivation for always having =E2=80=9Csub=E2=80=9D in the event payload,= rather than a normal claim, is that that=E2=80=99s how you think RISC even= ts will be structured, and that you want *all* events to also use the RISC event structuring.


This has absolutely nothing to do with RISC in particu= lar. Both the confusion problem and the RP issued SETs are generic SET prob= lems that need to be solved.

BTW, you never offere= d a solution to the RP issued SETs problem MIke. Can you please do that?

=C2=A0

=C2= =A0 To my way of thinking, if you really believe that you should be asking = the SET spec to be withdrawn from the IETF and only define RISC events in t= he RISC working group.=C2=A0 But in fact, requiring all events to follow th= e RISC conventions makes no more sense than requiring all JWTs to be ID Toke= ns.=C2=A0 That would have made JWTs useless for many use cases.=C2=A0 Propo= sing to limit claims usage in SETs would likewise make them inapplicable fo= r many non-RISC use cases.

=C2=A0

We have a potential su= ccess on our hands.=C2=A0 Let=E2=80=99s not screw it up by making it unnece= ssarily complicated.


Sure, let's solve all open issues first.
=C2=A0
=

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mail= to:mscurtescu@google.com]
Sent: Wednesday, June 21, 2017 1:53 PM
To: M.Lizar@OCG <m.lizar@openconsentgroup.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Richa= rd Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Justin Richer <jricher@= mit.edu>; Yaron Sheffer <yaronf.ietf@gmail.com>; ID Event= s Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG <m.lizar@openconsentgroup.com> wrote:=

FWIW - I agree with Mike that pu= tting restrictions on the "sub" claim usage would unnecessarily c= omplicate SETs for some use cases.

=C2=A0

sub is defined as optional in JWT, so technically we= are not adding any restrictions. Do you have examples of use cases that ca= nnot handle sub at the event level?

=C2=A0

=C2=A0

=C2=A0

It= s a lot easier to add to a spec and very=C2=A0difficult=C2=A0(if not imposs= ible) to retract.

=C2=A0

I agree. I don't think anything is retracted.=

=C2=A0

Again, see:

=C2=A0

Last sentence of 4.1.2 states "Use of this clai= m is OPTIONAL."

=C2=A0

=C2=A0

In= this regard, keeping it simple is critical for broad adoption.=C2=A0

=C2=A0

Ma= rk

=C2=A0

On 19 Jun 2017, at 16:55, Marius Scurtescu <mscu= rtescu@google.com> wrote:

=C2=A0

Mike, are you suggesting we define SETs in such a wa= y that they will not work for RISC? A top level iss+sub is clearly not work= ing for RISC, and may not work for logout either if you allow logout to be = initiated from an RP.


Marius

=C2=A0

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Marius, there=E2=80=99= s nothing stopping you (or the RISC working group or other profiles) from d= efining events that can be sent from RPs to IdPs now, without any changes to the SET spec.=C2=A0 Specify the claims you want to use, and= you=E2=80=99re golden.

=C2=A0

But it would be counte= rproductive to require all other SETs to meet the requirements of your spec= ific profile.=C2=A0 There are simpler use cases that can use claims in simpler ways.=C2=A0 Trying to make the simple use cases be c= omplex will have the side effect of limiting the adoption of the spec, whic= h wouldn=E2=80=99t be good for anyone.

=C2=A0

If successful, SETs wi= ll have many different profiles.=C2=A0 That=E2=80=99s a sign of success =E2= =80=93 not a sign of weakness.

=C2=A0

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

=C2= =A0

From: Marius Scurtescu [mailto:<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Justin Richer <jricher@mit.edu>= ;; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org= >; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

=C2=A0

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones &l= t;Michael.Jones@microsoft.com> wrote:

I=E2=80=99m sorr= y to be slow replying to some messages in this thread.=C2=A0 I have a lot o= f other things on my plate, but I will take the time now to reply, because I whole= heartedly disagree with some of the statements below and believe it would b= e severely harmful to the specification and its adoption to act upon them.= =C2=A0 Specifically:

=C2=A0=

Solving the confusion is one problem. The othe= r problem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top leve= l iss is different from the iss of the sub, a top level sub is not possible= .

=C2=A0

And I don't want to downplay the confusion= problem either. I think it is a real concern and I think a solid solution is important.

=C2=A0

The OpenID Working Group designed logout token= s without secevent in mind. I agree we should not recklessly break compatibility, but to me it seems necessary in this case.

=C2=A0

  • =C2=A0

=C2=A0=

=C2=A0

Further iss ruies are absolutely needed for th= e RP to IdP case described above.

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0=

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to b= e used for some profiles to differentiate between kinds of JWTs.=C2=A0 Its = use should not be mandated in the SET spec.=C2=A0 I would oppose duplicatin= g the =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a dupli= cative meaning.

If typ can be use and no other claim is needed= , then let's talk about that. I do think SET should mandate it. I don't understand why not. Can you please propose with examples how c= an typ be used?

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0=

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of JWT can ever use the "nonce=E2=80=9D claim.= =E2=80=9D=C2=A0 This reflects a misunderstanding.=C2=A0 It=E2=80=99s the *<= b>value* of the nonce that self-secures the JWT =E2=80=93 not that any =E2=80=9Cnonce=E2=80=9D claim is present.= =C2=A0 Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D with= out any risk of conflict, since the nonce value is a cryptographically secu= re random number.

=C2=A0

For SETs I cannot see how the nonce value is u= seful. That value is not passed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage o= f the JWT, a very weak solution to the confusion problem.

=C2=A0

  • =C2=A0

=C2=A0=

Will some of you= be at the Cloud Identity Summit next week?=C2=A0 I=E2=80=99d be glad to ha= ve in-person discussions about these topics there.

=C2=A0=

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

=C2=A0=

P.S.=C2=A0 Food = for thought:=C2=A0 Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any oth= er claim) or forcing it to be located in a non-standard location makes about as much sense as a= rbitrarily saying that, for a particular profile, the Latin word for subjec= t =E2=80=9Csubiectum=E2=80=9D must be used as the claim name instead of =E2= =80=9Csub=E2=80=9D.=C2=A0 Yes, it will completely differentiate this profile from others not spelling the claim name this way, but it would cer= tainly be an impediment to the use of standard JWT libraries and to interop= erability.

=C2=A0

If we define that sub must be at the event lev= el then it is at a standard location, I don't see what the issue is. The impediment you mention is the actual solution. I don't think t= hat a JWT library that was written for Id Tokens should be used to parse SE= Ts. The library has to be SET aware, in which case the event level iss+sub = is not an issue at all.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Yaron Sheffer [mailto:yaronf.ietf@gmai= l.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscu= rtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike = Jones <Michael.Jones@microsoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hu= nt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules f= or "sub" and "iss" that can be defined in the SET spec.=

Almost everybody agrees on a long-term "usage" claim ("ty= pe" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use = it in the SET document before it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <m= scurtescu@google.com> wrote:

=C2=A0

+1 to what Annabelle said.

=C2=A0

Also, Mike you are missing the other requirement, fo= r RPs to send events to an IdP. The iss+sub pair at the top level is broken= in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <= ;phil.hunt@oracle.com> wrote:

+1

=C2=A0

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.= com> wrote:

Mike,

=C2=A0

Your explanation for why this is a non-problem is de= pendent upon side effects of elements of OpenID Connect that were not desig= ned to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certain that= a nonce-less ID Token is really an ID Token. Any party that the caller pas= ses the ID Token off to has no way to verify its provenance.<= /p>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem again.<= u>

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim.=

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that cares a= bout disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and r= eplay attacks are both things that happen. What=E2=80=99s being proposed is= a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use commo= n libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library co= uld handle disambiguation for any JWT profile, whereas with the status quo = each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike J= ones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <= ;henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

You=E2=80=99ve heard o= f =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d characterize = the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2= =80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0

Mandatory solutions ar= e being proposed in this thread to problems that there=E2=80=99s no evidenc= e that we actually even have.=C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.h= tml.=C2=A0 If people have data showing that this is possible with speci= fic kinds of Access Tokens or other real JWT deployments, please provide sp= ecifics, so that we can use that data to inform appropriate engineering choices on our part.

=C2=A0

The proposed =E2=80=9C= solutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80=9D in= the normal way, or requiring a type claim, would make previously simple th= ings unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-bounces@= ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkho= lz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain w= hat you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better analogy wou= ld be the X.509 Key Usage extension: a multi-valued property that declares = the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to i= t in some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius= Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.d= e>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank" class= =3D"cremed">henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target clie= nt, but not the intended usage (access token to authorize resource access o= r SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.<= /p>

=C2=A0

I don't know what do you mean by "intend&qu= ot; (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Di= ck Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matak= e.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.co= m <mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gma= il.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" class=3D"cremed">adaw= es@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wro= te:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracl= e.com <mailto:phil.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:mscurtescu@google.com>> wrote:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-= event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxP= EivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6mi= RiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&a= mp;e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event= @ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org = <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |ad= awes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>= |+1= 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>

=C2=A0

=C2=A0<= /p> 

_______________________________________________

Id-event mailing list


Id-event@ietf.org


https://www.ietf.org/mailman/listinfo/id-event=

=C2=A0

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>

=C2=A0

=C2=A0


--001a113ee31e1bb45f05527eeebb-- From nobody Wed Jun 21 14:35:58 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A904A124B0A for ; Wed, 21 Jun 2017 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRBd7kxTc2Pn for ; Wed, 21 Jun 2017 14:35:52 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A4C127873 for ; Wed, 21 Jun 2017 14:35:52 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id t87so11822141ioe.0 for ; Wed, 21 Jun 2017 14:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a98cQyMw7QuZ9DKD5yxb6vHELEqTGsw13tX9oji8WUs=; b=ikKlO2vsHidv/hCRN2NMq1eraylr9hsVqTIVryQcuyBQ4i5yCPgrXY6KHqrAr4bQHF KnaYu/xMzImSbECQ6UJ90n8lij1FAwcRCIbQvFV1H5HTCvfho1+WH2O3Mj40V1NdjIAP 5SVUi2XfAzM07+ZGzBuBbDOHA0/21jQhugnqR1xskAhvrs7MjqeVoA8XwEiTIw+acrSk Q1q8n4pHhrZW74BXifBkPoKU4U5G4O0FNF1U7YYDg/ctTGlzdSSb4wsbCU0oxKK694Nm QZAWDyJ368BcpNNZsdZNR7Yq2N51ZZXX39+HJEdTRxi8gBg5bF0HpatMf7GYqphACFir 3tKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a98cQyMw7QuZ9DKD5yxb6vHELEqTGsw13tX9oji8WUs=; b=TGq1f4X8jHqOJt91ByFjEJblypyS35lAPgAA7bqfb6y8/UZPDB1fatzA9g3dQI5AFc Xkm//N7jz40DR9rKVGm4LAkbV2K6LhYSBOIlhpUiOAJvxjJpObSSooBePxYTbRty/03b hGpF4xc49Xp0Vyt5CIJ2C0/PQQrGWhM4s6HXFVftiIMqvVO2IRc+3b0/H+hFkSkKQ3f6 DjyIjqGdZfVB1bPj+q4XhCm97cCfuymSx6DWgFKHY6R78c5iDWWfyw5fKemdqeQVI34u eW93txSR1xoHnb9bCkb5Ucv1Etk4rw/PcsmGou8SjRUWypkzPZzkKI6Eqhn+j9jXQFXg a7qA== X-Gm-Message-State: AKS2vOx55yl+ShtW2gBSE5Gbmbwa00xoB0I3Uzz/fJuLyjsE0Y3P2dTe ctBEpNLkFFzYDVhO2y7fGOr8cRilpBpm X-Received: by 10.107.36.3 with SMTP id k3mr36290390iok.130.1498080951119; Wed, 21 Jun 2017 14:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Wed, 21 Jun 2017 14:35:30 -0700 (PDT) In-Reply-To: <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> From: Marius Scurtescu Date: Wed, 21 Jun 2017 14:35:30 -0700 Message-ID: To: John Bradley Cc: Yaron Sheffer , Justin Richer , Annabelle Richard , Phil Hunt , Michael Jones , ID Events Mailing List , Henk Birkholz Content-Type: multipart/alternative; boundary="001a1140f978f0405f05527f26e6" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:35:56 -0000 --001a1140f978f0405f05527f26e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2017 at 1:39 PM, John Bradley wrote: > In the envelope typ is a media/mime type. Registering application/idt+jw= t > if we register jwt as a structured name sufix. > > Using the cty is also possible. I need to think about what is better bu= t > we can agree on a convention. > > Not everything is going to be a set token like not every JWS is a JWT. > > If we are going to define processing rules to stop collisions and > confusion around JWT for different purposes, we should just start using t= he > typ parameter based on the existing spec. > > In general content sniffing if there is more than one option eventually > gets you into trouble. > > I am not convinced that forcing there to be no sub at the top level is a > good idea. > > It is not the way we should differentiate between SET and id_tokens. > > If sub is not allowed at the top level people will do non SET JWT for > things where the subject is scoped to the iss of the token. > > I think defining sub to be part of the event for cases where the sub is > scoped differently from the issuer of the token is fine, but should not b= e > required for all event types. > Allowing sub at the event level as optional sounds good to me. If sub is present at the event level then it probably should not be at the top level. But, this optional approach makes the spec more complicated if anything. Same for SET libraries. While not necessarily a problem, iss+sub at the event level has another nice property. It allows transmitters to use different signing keys (and iss) for SETs, in some deployments this could be critical. > I think we should solve the confusion issue separately from the sub issue= . > Sure, they don't have to have the same solution. > > Sorry I am at CIS so trying to catch up on lists. > > John B. > > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote: > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > =E2=80=94 Justin > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > +1 to what Annabelle said. > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > Marius > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > >> +1 >> >> Phil >> >> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> Mike, >> >> >> Your explanation for why this is a non-problem is dependent upon side >> effects of elements of OpenID Connect that were not designed to solve th= is >> issue. As a result, I see several issues with it: >> >> 1. The caller of the Token Endpoint is the only party that can be >> certain that a nonce-less ID Token is really an ID Token. Any party that >> the caller passes the ID Token off to has no way to verify its provenanc= e. >> >> 2. Any future ID Token distribution method needs to solve this >> problem again. >> >> 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. >> >> 4. This is only a solution for ID Tokens. Every other JWT profile >> that cares about disambiguation has to invent its own solution to the >> problem. >> >> >> We know from experience that naming collisions and replay attacks are >> both things that happen. What=E2=80=99s being proposed is a simple, defe= nsive >> measure against these risks. You brought up JWT libraries: a general >> solution actually makes it easier to use common libraries for JWT parsin= g. >> A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation = for any JWT >> profile, whereas with the status quo each profile would require unique >> logic. >> >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> >> >> *From: *Id-event on behalf of Mike Jones < >> Michael.Jones@microsoft.com> >> *Date: *Wednesday, June 14, 2017 at 1:16 PM >> *To: *Marius Scurtescu >> *Cc: *"Richard Backman, Annabelle" , ID Events >> Mailing List , Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals >> in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 maki= ng things that can and >> should be simple complex, without data showing there=E2=80=99s any need = to do so. >> >> >> Mandatory solutions are being proposed in this thread to problems that >> there=E2=80=99s no evidence that we actually even have. It=E2=80=99s al= ready been >> established that it=E2=80=99s impossible for a SET to be confused for an= ID Token =E2=80=93 >> see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html >> . >> If people have data showing that this is possible with specific kinds of >> Access Tokens or other real JWT deployments, please provide specifics, s= o >> that we can use that data to inform appropriate engineering choices on o= ur >> part. >> >> >> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of= =E2=80=9Csub=E2=80=9D in the >> normal way, or requiring a type claim, would make previously simple thin= gs >> unnecessarily complex. Yes, then the result is then different than a >> normal JWT but a consequence of this is that custom parsing code would h= ave >> to be used, rather than a standard JWT parser. The more unwieldy we mak= e >> it to use SETs, the more likely developers are to just create their own >> data structures. Keeping it simple is the key to adoption. Standards a= re >> only useful if they are actually used. >> >> >> -- Mike >> >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org >> ] *On Behalf Of *Richard Backman, Annabelle >> *Sent:* Tuesday, June 13, 2017 5:33 PM >> *To:* Marius Scurtescu ; Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> >> *Cc:* ID Events Mailing List >> *Subject:* Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? >> >> >> To your first question, I think a better analogy would be the X.509 Key >> Usage extension: a multi-valued property that declares the intended purp= ose >> of the JWT, and that a recipient may refer to when determining whether t= o >> accept a JWT being presented to it in some context. >> >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> >> >> *From: *Id-event on behalf of Marius >> Scurtescu >> *Date: *Tuesday, June 13, 2017 at 11:05 AM >> *To: *Henk Birkholz >> *Cc: *ID Events Mailing List >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> >> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < >> henk.birkholz@sit.fraunhofer.de> wrote: >> >> And a 2nd question. >> >> What semantics would "usage" provide that that are not covered via >> "intend", "audience", and "scope"? >> >> >> >> "aud" (audience) specifies the target client, but not the intended usage >> (access token to authorize resource access or SET to communicate a secur= ity >> event?) >> >> >> "scope" is not used by SET. >> >> >> I don't know what do you mean by "intend" (or intent)? >> >> >> >> >> >> Henk >> >> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >> >> Thanks for putting this together! >> >> I think the assumptions inherent in 3.9 are flawed: >> >> =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutu= ally exclusive >> set of valid claims and/or header parameters, and enforcing this require= s a >> =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that = JWTs from some >> future spec can=E2=80=99t be mistaken for JWTs from a current spec. >> >> =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80= =9Cdifferent >> keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by the = spec or >> not, implementers will ignore this because managing one key is easier th= an >> managing N different keys. >> >> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. >> >> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter. >> >> -- >> >> Annabelle Richard Backman >> >> Identity Services >> >> *From: *Id-event on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Monday, June 12, 2017 at 3:18 PM >> *To: *Marius Scurtescu >> *Cc: *Adam Dawes , "matake, nov" , ID >> Events Mailing List , "Phil Hunt (IDM)" < >> phil.hunt@oracle.com> >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> >> Agreed. Note that there is still lots of discussion on what should be in >> 3.9. >> >> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > > wrote: >> >> Thanks for the pointer Dick, very good timing :-) >> >> The issue is described by "2.7. Cross-JWT Confusion" and the >> mitigation is in "3.9. Use Mutually Exclusive Validation Rules for >> Different Kinds of JWTs", specifically "Use different sets of >> required claims...", "Use different keys for different kinds of >> JWTs." and "Use different issuers for different kinds of JWTs.". >> >> I still think that a "type" claim would bring a lot of clarity and >> safety. >> >> >> Marius >> >> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > > wrote: >> >> Yaron, Mike and I just published an BCP ID for JWT >> http://self-issued.info/?p=3D1690 >> >> >> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > > wrote: >> >> I was initially a fan of keeping SETS to be very similar to >> id tokens but I now think this is a better plan. >> >> On Thu, Jun 8, 2017 at 6:56 PM matake, nov > > wrote: >> >> +1 especially for "type" >> >> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >> >: >> >> +1 >> >> Phil >> >> >> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> > >> > wrote: >> > >> > There were a couple of proposals on how to >> distinguish SETs from Id Tokens and Access Tokens in >> such a way that naive implementations will not >> confuse one for the other and open up security >> vulnerabilities. >> > >> > There is also another important requirement: the >> SET issuer in some cases must be different from the >> "sub" issuer. This is the case of an RP sending SETs >> to an IdP. >> > >> > With these requirements in mind I propose the >> following: >> > - both "sub" and "iss" to be defined at the event >> level >> > - "iss" at event level and at top SET level can >> be different >> > - "iss" and "sub" at event level can be different >> across events in the same SET >> > - "sub" should NOT be present at the top SET >> level (this solves the disambiguation), please note >> "should" and not "must" >> > >> > This solution also allows different profiles that >> define event types to define additional claims >> related to sub (like email or phone_number) and >> since all these claims will be at the event level >> there will be no collisions or ambiguity. >> > >> > Another proposal (which I supported) was to >> define a composite "aud" claim. This is not solving >> the requirement for a distinct SET issuer. Also, >> having the same claim name having different syntax >> in different token types could lead to confusion. >> > >> > And yet another proposal was to introduce a new >> claim for JWTs that defines a "type". This is not >> practical in the short term, and it also is not >> solving the distinct issuer requirement, but I think >> this is something the JWT group should seriously >> consider. >> > >> > Thoughts? >> > >> > Marius >> >> > _______________________________________________ >> > Id-event mailing list >> >> > Id-event@ietf.org >> > >> https://urldefense.proofpoint. >> com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Dev >> ent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10& >> r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp >> 74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88 >> YKOCd0mxPQFJLhxWI&e=3D >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> -- >> Adam Dawes | Sr. Product Manager |adawes@google.com >> |+1 650-214-2410 >> <%2B1%20650-214-2410> >> > >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> -- >> Subscribe to the HARDTWARE > > >> mail list to >> learn about projects I am working on! >> >> >> >> -- >> >> Subscribe to the HARDTWARE > > >> mail list to learn about projects I am working on! >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz >> jWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_ >> 3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D >> >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing listId-event@ietf.orghttps://www.ietf.org/mailman/listin= fo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > --001a1140f978f0405f05527f26e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 1:39 PM, John Bradley <ve7jtb@ve7jtb.= com> wrote:
In the envelope typ is a media/mime type.=C2=A0 Regist= ering application/idt+jwt if we register jwt as a structured name sufix. = =C2=A0

Using the cty is also possible. =C2=A0 I need to = think about what is better but we can agree on a convention.

Not everything is going to be a set token like not every JW= S is a JWT.

If we are going to define processing r= ules to stop collisions and confusion around JWT for different purposes, we= should just start using the typ parameter based on the existing spec.

In general content sniffing if there is more than one = option eventually gets you into trouble.

I am not = convinced that forcing there to be no sub at the top level is a good idea. = =C2=A0

It is not the way we should differentiate b= etween SET and id_tokens.

If sub is not allowed at t= he top level people will do non SET JWT for things where the subject is sco= ped to the iss of the token.

I think defining sub = to be part of the event for cases where the sub is scoped differently from = the issuer of the token is fine, but should not be required for all event t= ypes.

Allowing sub = at the event level as optional sounds good to me. If sub is present at the = event level then it probably should not be at the top level.

=
But, this optional approach makes the spec more complicated if a= nything. Same for SET libraries.

While not necessa= rily a problem, iss+sub at the event level has another nice property. It al= lows transmitters to use different signing keys (and iss) for SETs, in some= deployments this could be critical.


=
I think we should solve the confusion issue separately from the sub is= sue.

Sure, they don= 't have to have the same solution.

=C2=A0

Sorry I am at CIS so trying to catch up on lists.

John B.

On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <= ;yaronf.ietf@gmail.com> wrote:

=20 =20 =20

So to summarize what I'm= seeing on this thread:

Everybody agrees with Marius's short-term= solution, specific rules for "sub" and "iss" that can be defined in = the SET spec.

Almost everybody agrees on a long-term "usage"= ; claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usag= e" claim, we need to also use it in the SET document before it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron


On 15/06/17 22:08, = Justin Richer wrote:
=20 +1 to this as well.

=C2=A0=E2=80=94 Justin

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

=20
+1 to what Annabelle said.

Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracl= e.com> wrote:
+1

Phil

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com&g= t; wrote:

Mike,

=C2=A0

Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem again.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim= .

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and replay attacks are both things that happen. What=E2=80=99s being proposed is a simp= le, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A =E2=80=9Cusage-aware=E2= =80=9D JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Ident= ity Services

=C2=A0
=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <= Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com<= /a>>
Cc: "Richard Backman, Annabelle" <richanna= @amazon.com>, ID Events Mailing List <id-event@ietf= .org>, Henk Birkholz <henk.bir= kholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

=C2=A0

You=E2=80=99ve heard of =E2=80=9Cpremat= ure optimization=E2=80=9D.=C2=A0 I=E2=80=99= d characterize the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D= =E2=80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.

=C2=A0<= br class=3D"m_3393399402947266561webkit-block-placeholder">

Mandatory = solutions are being proposed in this thread to problems that there=E2=80=99s no eviden= ce that we actually even have.=C2=A0 It=E2= =80=99s already been established that it=E2=80= =99s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archiv= e/web/id-event/current/msg00428.html.=C2=A0 If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.=

=C2=A0

The proposed = =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80= =9Csub=E2=80=9D in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser.=C2= =A0 The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key to adoption.=C2=A0 Standards ar= e only useful if they are actually used.

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-b= ounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.co= m>; Henk Birkholz <henk.b= irkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org= >
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question= : can you explain what you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first q= uestion, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Ident= ity Services

=C2=A0
=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <ms= curtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.frau= nhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org&g= t;
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkho= lz@sit.fraunhofer.de> wrote:

= And a 2nd question.

What semantics would "usage&= quot; provide that that are not covered via "intend", "audience", and "s= cope"?

=C2=A0

"aud= " (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)

=C2=A0

"sco= pe" is not used by SET.

=C2=A0

I don'= ;t know what do you mean by "intend" (or intent)?

=C2=A0
=C2=A0

=

Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarante= e that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a =E2=80=9Cfail o= n an unrecognized claim=E2=80=9D app= roach to ensure that JWTs from some future spec can=E2=80=99t = be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expe= ct implementers to adhere to the =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80= =9D rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2= =80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D= or =E2=80=9Cusage=E2=80=9D claim/header parameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-ev= ent-bounces@ietf.org> on behalf of Dick Hardt <dic= k.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <msc= urtescu@google.com>
*Cc: *Adam Dawes <adawes@google= .com>, "matake, nov" <nov@matake= .jp>, ID Events Mailing List <id-even= t@ietf.org>, "Phil Hunt (IDM)" <= ;phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscur= tescu@google.com <mailto:mscurtescu@google.c= om>> wrote:

=C2=A0 =C2=A0 Thanks for the po= inter Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is desc= ribed by "2.7. Cross-JWT Confusion" and the
=C2=A0 =C2=A0 mitigation is in = "3.9. Use Mutually Exclusive Validation Rules for
=C2=A0 =C2=A0 Different Kinds o= f JWTs", specifically "= Use different sets of
=C2=A0 =C2=A0 required claims..= .", "Use different keys for different kinds of
=C2=A0 =C2=A0 JWTs." and &= quot;Use different issuers for different kinds of JWTs.".=

=C2=A0 =C2=A0 I still think tha= t a "type" claim would br= ing a lot of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 20= 17 at 9:59 PM, Dick Hardt <dick.ha= rdt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.h= ardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yar= on, Mike and I just published an BCP ID for JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-is= sued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On = Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@g= oogle.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;mailto:adawes@google.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 I was initially a fan of keeping SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 id tokens but I now think this is a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:nov@matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for "type"=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com= >>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mscurtescu@google.com

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 <mailto:mscurtescu@goog= le.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 distinguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such a way that naive implementations will not =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confuse one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulnerabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET issuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "sub" issuer. Thi= s is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 following:
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - both "sub= " and "iss" to be defin= ed at the event
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - "iss"= ; at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be different
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - "iss"= ; and "sub" at event level can be different
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 across events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - "sub"= ; should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "should" and not = "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> This solution al= so allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 define event types to define additional claims =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 related to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there will be no collisions or ambiguity. =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 define a composite "au= d" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the requirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 having the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in different token types could lead to confusion. =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim for JWTs that defines a "type".= This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 practical in the short term, and it also is not =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solving the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consider.
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ___________________________= ____________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-event@ietf.org <mailto:Id-event@ietf.org&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv<= wbr>lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz<= wbr>jWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqm= g&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________________________<= wbr>_________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ______________________________<= wbr>_________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Adam Dawes | Sr. Product Manager |adawes@google.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ______________________________<= wbr>_________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sub= scribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lea= rn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/= listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/= listinfo/id-event

=C2=A0

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.i=
etf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing li= st
Id-event@ietf.org
https://www.ietf.org/mailman= /listinfo/id-event


--001a1140f978f0405f05527f26e6-- From nobody Wed Jun 21 14:55:44 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2149A1294BF for ; Wed, 21 Jun 2017 14:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-rKEqvOUOvg for ; Wed, 21 Jun 2017 14:55:38 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD0C1294DB for ; Wed, 21 Jun 2017 14:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1498082111; x=1529618111; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7DuMOcPq1CXFSbpbWtMO15kP0YzVLYZxDX29rY97mFM=; b=AJXilaLvPHIOSb8xucY3+S8qNyoNshYDbxIOrWCY0rW96e9HK9DAdmCq SgY2sNsQu1P+IsZNbpLGR9KN0Jib0GGFTHdUDO+0bUXQnNEZsrgQdYuLW /XrhE7XuH7aY8Qn0cy/IazzCk03birKQhfh0aHN230wiVrLkOOcTrTBxM w=; X-IronPort-AV: E=Sophos;i="5.39,370,1493683200"; d="scan'208,217";a="289255504" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-62006.pdx2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 21:55:00 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-62006.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP id v5LLsvGm030883 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2017 21:54:58 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Jun 2017 21:54:57 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Jun 2017 21:54:57 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Wed, 21 Jun 2017 21:54:57 +0000 From: "Richard Backman, Annabelle" To: "Phil Hunt (IDM)" , John Bradley CC: Henk Birkholz , Justin Richer , Marius Scurtescu , Yaron Sheffer , Michael Jones , "ID Events Mailing List" Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwAgAEftACAAJUjgP//9x6AgAG/8QD//9AlgAAO8LsAACLOTQAABCSqAABn9XkAAMj4pQD//468gIAAdqeAgAAD8ID//5ZlAA== Date: Wed, 21 Jun 2017 21:54:57 +0000 Message-ID: <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> In-Reply-To: <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.82] Content-Type: multipart/alternative; boundary="_000_370B5025BD044B059FFDD8850230BBBFamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:55:43 -0000 --_000_370B5025BD044B059FFDD8850230BBBFamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNwZWMgc2F5cyB0aGF0IHRoZSBldmVudHMgY2xhaW0gU0hPVUxEIE5PVCBiZSB1c2VkIHRv IGV4cHJlc3MgbXVsdGlwbGUgbG9naWNhbCBldmVudHMuIElmIGl04oCZcyBhbHNvIG5vdCB1c2Vk IHRvIGV4cHJlc3MgZXZlbnRzIGZyb20gZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQgY29ycmVzcG9u ZCB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChlLmcuIGFuIE9JREMgYmFja2NoYW5uZWwgbG9n b3V0IGV2ZW50IGFsb25nc2lkZSBhIGh5cG90aGV0aWNhbCBSSVNDIGxvZ291dCBldmVudCksIHRo ZW4gSeKAmW0gbm90IHN1cmUgd2hhdCB1c2UgY2FzZSB0aGF0IGxlYXZlcyBmb3IgbXVsdGlwbGUg ZXZlbnRzIGluIG9uZSBTRVQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVu dGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUuY29t Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IGF0IDI6MTIgUE0NClRvOiBKb2huIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPg0KQ2M6ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNp dC5mcmF1bmhvZmVyLmRlPiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiwgTWFyaXVz IFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPiwgWWFyb24gU2hlZmZlciA8eWFyb25m LmlldGZAZ21haWwuY29tPiwgTWljaGFlbCBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBh bmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpTZXBhcmF0ZSBvciBjb21iaW5lZCBtYXkgYmUgZXZv bHZpbmcuIE1pa2Ugd2FudHMgdG8ga2VlcCB0aGUgY3VycmVudCBiYWNrY2hhbm5lbCBsb2dvdXQg dmVyeSBuYXJyb3dseSBzY29wZWQuIEhlIHN1Z2dlc3RlZCByaXNjIGRlZmluZSBpdHMgb3duIGR1 cGxpY2F0ZSBkZWZpbml0aW9ucyBhbmQgbWVhbmluZ3MuDQoNClRoYXQgbGVhZHMgbWUgdG8gYmVs aWV2ZSB3ZSB3aWxsIGhhdmUgbXVsdGktdHlwZSBldmVudHMgaW4gcHJhY3RpY2UuDQoNClNlc3Np b24gY2FuY2VsbGF0aW9uIGNhbiBvY2N1ciBmb3IgbWFueSByZWFzb25zLiBPbmUgb2YgdGhlIGRp ZmZlcmVudGlhdG9ycyB3ZSBoYWQgdHJpZWQgdG8gbWFrZSB3YXMgYW4gYXNzdW1wdGlvbiB0aGF0 IHVzZXIgaW5pdGlhdGVkIGV2ZW50cyB3b3VsZCBiZSBwYXJ0IG9mIGNvbm5lY3QuIFJpc2sgd291 bGQgY292ZXIgdmFyaWF0aW9ucyB0aGF0IGRyaXZlIG9mZiBvZiByaXNrIGNhbGN1bGF0aW9ucyBs aWtlIHBhc3N3b3JkIHJlc2V0Lg0KDQpUaGVyZSBhcmUgYWxzbyBzaWdub3V0IGV2ZW50cyBhdCBy cCdzIHRvIGxldCB0aGUgT1Aga25vdy4gVGhlc2UgYXJlIG5vdCBjb21tYW5kcyBidXQgbm90aWZp Y2F0aW9uIHRoYXQgYSByZXNvdXJjZSBzZXNzaW9uIGlzIGNhbmNlbGxlZC4gSU9XIHNpbmdsZSBz aWduIG91dCBub3QgZXhwZWN0ZWQuDQoNClBoaWwNCg0KT24gSnVuIDIxLCAyMDE3LCBhdCAxOjU4 IFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbT4+IHdyb3RlOg0KSSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBhcmUgb25seSBhbGxv d2luZyBzZXQgbWVzc2FnZXMgZm9ybSB0aGUgc2FtZSBmYW1pbHkgdGhhdCBhZ3JlZSBvbiB0b3Ag bGV2ZWwgY2xhaW1zLg0KDQpPdGhlcndpc2UgdGhlcmUgY2FuIGJlIG5vIHRvcCBsZXZlbCBjbGFp bXMgYW5kIHdlIGFyZSByZWFsbHkgZGVmaW5pbmcgYSBhbHRlcm5hdGl2ZSBmb3JtYXQgdG8gSldU IGluIHNvbWUgd2F5cy4NCg0KSm9obiBCLg0KDQpPbiBKdW4gMjEsIDIwMTcsIGF0IDM6NTQgUE0s IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCBKb2huIHRoYXQgdGhl IEpXVCB0eXBlIGNvbmZ1c2lvbiBwcm9ibGVtIGFuZCB0aGUgU0VUIHN1YiBwcm9ibGVtIGNhbiBh bmQgc2hvdWxkIGJlIGRpc2N1c3NlZCBzZXBhcmF0ZWx5LiBUaGUgc2VjZXZlbnRzIFdHIGlzIHBy b2JhYmx5IG5vdCB0aGUgcmlnaHQgc2V0dGluZyB0byBkaXNjdXNzIHRoZSBmb3JtZXIuDQoNCk15 IGNvbmNlcm4gd2l0aCB0aGUgc3ViIGNsYWltIGlzIHRoYXQgdHdvIHByb2ZpbGVzIG1heSBkaWN0 YXRlIGNvbmZsaWN0aW5nIHNlbWFudGljcyAoZS5nLiBQcm9maWxlIEEgc2F5cyBpdOKAmXMgYSBw aG9uZSBudW1iZXIsIFByb2ZpbGUgQiBzYXlzIGl04oCZcyBhbiBlbWFpbCBhZGRyZXNzKS4gSWYg dGhlc2UgcHJvZmlsZXMgZG9u4oCZdCBwcm92aWRlIGFuIGFsdGVybmF0ZSB3YXkgdG8gZGVjbGFy ZSBzdWJqZWN0IG9mIHRoZWlyIGV2ZW50cywgdGhlbiB0aGV5IGNhbm5vdCBiZSBwcmVzZW50IHdp dGhpbiB0aGUgc2FtZSB0b2tlbi4gVGhpcyBpbmNvbXBhdGliaWxpdHkgdHJhcCBzZWVtcyBsaWtl IHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGVhc2lseSBtaXNzZWQgYnkgZ3JvdXBzIHByb2ZpbGlu ZyBTRVQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNl cw0KDQoNCkZyb206IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0 YkB2ZTdqdGIuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyBhdCAxOjM5IFBN DQpUbzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYu aWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWls dG86anJpY2hlckBtaXQuZWR1Pj4sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xl LmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4sIEFubmFiZWxsZSBSaWNoYXJkIDxy aWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIFBoaWwgSHVu dCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4sIE1p Y2hhZWwgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGll dGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCBIZW5rIEJpcmtob2x6IDxoZW5rLmJp cmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3Mg VG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCkluIHRoZSBlbnZlbG9w ZSB0eXAgaXMgYSBtZWRpYS9taW1lIHR5cGUuICBSZWdpc3RlcmluZyBhcHBsaWNhdGlvbi9pZHQr and0IGlmIHdlIHJlZ2lzdGVyIGp3dCBhcyBhIHN0cnVjdHVyZWQgbmFtZSBzdWZpeC4NCg0KVXNp bmcgdGhlIGN0eSBpcyBhbHNvIHBvc3NpYmxlLiAgIEkgbmVlZCB0byB0aGluayBhYm91dCB3aGF0 IGlzIGJldHRlciBidXQgd2UgY2FuIGFncmVlIG9uIGEgY29udmVudGlvbi4NCg0KTm90IGV2ZXJ5 dGhpbmcgaXMgZ29pbmcgdG8gYmUgYSBzZXQgdG9rZW4gbGlrZSBub3QgZXZlcnkgSldTIGlzIGEg SldULg0KDQpJZiB3ZSBhcmUgZ29pbmcgdG8gZGVmaW5lIHByb2Nlc3NpbmcgcnVsZXMgdG8gc3Rv cCBjb2xsaXNpb25zIGFuZCBjb25mdXNpb24gYXJvdW5kIEpXVCBmb3IgZGlmZmVyZW50IHB1cnBv c2VzLCB3ZSBzaG91bGQganVzdCBzdGFydCB1c2luZyB0aGUgdHlwIHBhcmFtZXRlciBiYXNlZCBv biB0aGUgZXhpc3Rpbmcgc3BlYy4NCg0KSW4gZ2VuZXJhbCBjb250ZW50IHNuaWZmaW5nIGlmIHRo ZXJlIGlzIG1vcmUgdGhhbiBvbmUgb3B0aW9uIGV2ZW50dWFsbHkgZ2V0cyB5b3UgaW50byB0cm91 YmxlLg0KDQpJIGFtIG5vdCBjb252aW5jZWQgdGhhdCBmb3JjaW5nIHRoZXJlIHRvIGJlIG5vIHN1 YiBhdCB0aGUgdG9wIGxldmVsIGlzIGEgZ29vZCBpZGVhLg0KDQpJdCBpcyBub3QgdGhlIHdheSB3 ZSBzaG91bGQgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIFNFVCBhbmQgaWRfdG9rZW5zLg0KDQpJZiBz dWIgaXMgbm90IGFsbG93ZWQgYXQgdGhlIHRvcCBsZXZlbCBwZW9wbGUgd2lsbCBkbyBub24gU0VU IEpXVCBmb3IgdGhpbmdzIHdoZXJlIHRoZSBzdWJqZWN0IGlzIHNjb3BlZCB0byB0aGUgaXNzIG9m IHRoZSB0b2tlbi4NCg0KSSB0aGluayBkZWZpbmluZyBzdWIgdG8gYmUgcGFydCBvZiB0aGUgZXZl bnQgZm9yIGNhc2VzIHdoZXJlIHRoZSBzdWIgaXMgc2NvcGVkIGRpZmZlcmVudGx5IGZyb20gdGhl IGlzc3VlciBvZiB0aGUgdG9rZW4gaXMgZmluZSwgYnV0IHNob3VsZCBub3QgYmUgcmVxdWlyZWQg Zm9yIGFsbCBldmVudCB0eXBlcy4NCg0KSSB0aGluayB3ZSBzaG91bGQgc29sdmUgdGhlIGNvbmZ1 c2lvbiBpc3N1ZSBzZXBhcmF0ZWx5IGZyb20gdGhlIHN1YiBpc3N1ZS4NCg0KU29ycnkgSSBhbSBh dCBDSVMgc28gdHJ5aW5nIHRvIGNhdGNoIHVwIG9uIGxpc3RzLg0KDQpKb2huIEIuDQoNCk9uIEp1 biAxNywgMjAxNywgYXQgMzo0NSBQTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwu Y29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KU28gdG8gc3VtbWFy aXplIHdoYXQgSSdtIHNlZWluZyBvbiB0aGlzIHRocmVhZDoNCkV2ZXJ5Ym9keSBhZ3JlZXMgd2l0 aCBNYXJpdXMncyBzaG9ydC10ZXJtIHNvbHV0aW9uLCBzcGVjaWZpYyBydWxlcyBmb3IgInN1YiIg YW5kICJpc3MiIHRoYXQgY2FuIGJlIGRlZmluZWQgaW4gdGhlIFNFVCBzcGVjLg0KQWxtb3N0IGV2 ZXJ5Ym9keSBhZ3JlZXMgb24gYSBsb25nLXRlcm0gInVzYWdlIiBjbGFpbSAoInR5cGUiIGlzIHRh a2VuKSB0aGF0IHNob3VsZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJD UC4NCkRpZCBJIG1pc3MgYW55dGhpbmc/DQpCeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAidXNh Z2UiIGNsYWltLCB3ZSBuZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1lbnQgYmVm b3JlIGl0IGlzIHB1Ymxpc2hlZC4NClRoYW5rcywNCiAgICBZYXJvbg0KDQpPbiAxNS8wNi8xNyAy MjowOCwgSnVzdGluIFJpY2hlciB3cm90ZToNCisxIHRvIHRoaXMgYXMgd2VsbC4NCg0KIOKAlCBK dXN0aW4NCg0KT24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1IDxt c2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3Rl Og0KDQorMSB0byB3aGF0IEFubmFiZWxsZSBzYWlkLg0KDQpBbHNvLCBNaWtlIHlvdSBhcmUgbWlz c2luZyB0aGUgb3RoZXIgcmVxdWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4g SWRQLiBUaGUgaXNzK3N1YiBwYWlyIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYnJva2VuIGluIHRoaXMg Y2FzZS4NCg0KTWFyaXVzDQoNCk9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwg SHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPj4gd3JvdGU6DQorMQ0KDQpQaGlsDQoNCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwg UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCk1pa2UsDQoNCllvdXIgZXhwbGFuYXRpb24gZm9y IHdoeSB0aGlzIGlzIGEgbm9uLXByb2JsZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3Rz IG9mIGVsZW1lbnRzIG9mIE9wZW5JRCBDb25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8g c29sdmUgdGhpcyBpc3N1ZS4gQXMgYSByZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGgg aXQ6DQoNCjEuICAgICAgIFRoZSBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBv bmx5IHBhcnR5IHRoYXQgY2FuIGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4g aXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0 aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLg0K DQoyLiAgICAgICBBbnkgZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMg dG8gc29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLg0KDQozLiAgICAgIE5vIG90aGVyIHByb2ZpbGUg b2YgSldUIGNhbiBldmVyIHVzZSB0aGUgIm5vbmNl4oCdIGNsYWltLg0KDQo0LiAgICAgIFRoaXMg aXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpXVCBwcm9maWxl IHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVudCBpdHMgb3duIHNv bHV0aW9uIHRvIHRoZSBwcm9ibGVtLg0KDQpXZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5h bWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBo YXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVh c3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3UgYnJvdWdodCB1cCBKV1QgbGlicmFyaWVzOiBh IGdlbmVyYWwgc29sdXRpb24gYWN0dWFsbHkgbWFrZXMgaXQgZWFzaWVyIHRvIHVzZSBjb21tb24g bGlicmFyaWVzIGZvciBKV1QgcGFyc2luZy4gQSDigJx1c2FnZS1hd2FyZeKAnSBKV1QgbGlicmFy eSBjb3VsZCBoYW5kbGUgZGlzYW1iaWd1YXRpb24gZm9yIGFueSBKV1QgcHJvZmlsZSwgd2hlcmVh cyB3aXRoIHRoZSBzdGF0dXMgcXVvIGVhY2ggcHJvZmlsZSB3b3VsZCByZXF1aXJlIHVuaXF1ZSBs b2dpYy4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2Vz DQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE0NClRvOiBNYXJpdXMg U2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xl LmNvbT4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9u LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0 IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PiwgSGVuayBCaXJr aG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9s ekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBm b3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpZ b3XigJl2ZSBoZWFyZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiAgSeKAmWQgY2hh cmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBl c3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQgYmUgc2lt cGxlIGNvbXBsZXgsIHdpdGhvdXQgZGF0YSBzaG93aW5nIHRoZXJl4oCZcyBhbnkgbmVlZCB0byBk byBzby4NCg0KTWFuZGF0b3J5IHNvbHV0aW9ucyBhcmUgYmVpbmcgcHJvcG9zZWQgaW4gdGhpcyB0 aHJlYWQgdG8gcHJvYmxlbXMgdGhhdCB0aGVyZeKAmXMgbm8gZXZpZGVuY2UgdGhhdCB3ZSBhY3R1 YWxseSBldmVuIGhhdmUuICBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkIHRoYXQgaXTi gJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBhbiBJRCBUb2tlbiDi gJMgc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3Vy cmVudC9tc2cwMDQyOC5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50 X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZz PWVLTFRRUG1ZclYzVGhmRGJuOTBTQ3M1NVVST1RQaW5fbGdjNlJkcjVYb3cmZT0+LiAgSWYgcGVv cGxlIGhhdmUgZGF0YSBzaG93aW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmlj IGtpbmRzIG9mIEFjY2VzcyBUb2tlbnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBs ZWFzZSBwcm92aWRlIHNwZWNpZmljcywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBp bmZvcm0gYXBwcm9wcmlhdGUgZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC4NCg0KVGhl IHByb3Bvc2VkIOKAnHNvbHV0aW9uc+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9m IOKAnHN1YuKAnSBpbiB0aGUgbm9ybWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwg d291bGQgbWFrZSBwcmV2aW91c2x5IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBjb21wbGV4 LiAgWWVzLCB0aGVuIHRoZSByZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBK V1QgYnV0IGEgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUg d291bGQgaGF2ZSB0byBiZSB1c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIu ICBUaGUgbW9yZSB1bndpZWxkeSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtl bHkgZGV2ZWxvcGVycyBhcmUgdG8ganVzdCBjcmVhdGUgdGhlaXIgb3duIGRhdGEgc3RydWN0dXJl cy4gIEtlZXBpbmcgaXQgc2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uICBTdGFuZGFyZHMg YXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQt ZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgNToz MyBQTQ0KVG86IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86 bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0K Q2M6IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1l dmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQv QWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFY2hvaW5n IE1hcml1c+KAmXMgcXVlc3Rpb246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKA nGludGVuZOKAnT8NCg0KVG8geW91ciBmaXJzdCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBh bmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBLZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZh bHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVzIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBK V1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdo ZXRoZXIgdG8gYWNjZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRl eHQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0K DQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcml1cyBTY3VydGVzY3UgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6 IFR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU0NClRvOiBIZW5rIEJpcmtob2x6IDxo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5m cmF1bmhvZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g c29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBp c3N1ZXINCg0KT24gVHVlLCBKdW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiA8 aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZT4+IHdyb3RlOg0KQW5kIGEgMm5kIHF1ZXN0aW9uLg0KDQpXaGF0IHNlbWFu dGljcyB3b3VsZCAidXNhZ2UiIHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2aWEg ImludGVuZCIsICJhdWRpZW5jZSIsIGFuZCAic2NvcGUiPw0KDQoiYXVkIiAoYXVkaWVuY2UpIHNw ZWNpZmllcyB0aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFj Y2VzcyB0b2tlbiB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5p Y2F0ZSBhIHNlY3VyaXR5IGV2ZW50PykNCg0KInNjb3BlIiBpcyBub3QgdXNlZCBieSBTRVQuDQoN CkkgZG9uJ3Qga25vdyB3aGF0IGRvIHlvdSBtZWFuIGJ5ICJpbnRlbmQiIChvciBpbnRlbnQpPw0K DQoNCg0KDQpIZW5rDQoNCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIHdyb3RlOg0KVGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhDQoNCkkg dGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxhd2VkOg0KDQrCt1dl IGNhbuKAmXQgZ3VhcmFudGVlIHRoYXQgZXZlcnkgdHlwZSBvZiBKV1Qgd2lsbCBoYXZlIGEgbXV0 dWFsbHkgZXhjbHVzaXZlIHNldCBvZiB2YWxpZCBjbGFpbXMgYW5kL29yIGhlYWRlciBwYXJhbWV0 ZXJzLCBhbmQgZW5mb3JjaW5nIHRoaXMgcmVxdWlyZXMgYSDigJxmYWlsIG9uIGFuIHVucmVjb2du aXplZCBjbGFpbeKAnSBhcHByb2FjaCB0byBlbnN1cmUgdGhhdCBKV1RzIGZyb20gc29tZSBmdXR1 cmUgc3BlYyBjYW7igJl0IGJlIG1pc3Rha2VuIGZvciBKV1RzIGZyb20gYSBjdXJyZW50IHNwZWMu DQoNCsK3SXQgaXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUg dG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBy dWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdp bGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1h bmFnaW5nIE4gZGlmZmVyZW50IGtleXMuDQoNCsK3RGl0dG8gZm9yIOKAnGF1ZOKAnSBhbmQg4oCc aXNz4oCdIGNsYWltcy4NCg0KKzEgZm9yIGEg4oCcdHlwZeKAnSBvciDigJx1c2FnZeKAnSBjbGFp bS9oZWFkZXIgcGFyYW1ldGVyLg0KDQotLQ0KDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQoN CklkZW50aXR5IFNlcnZpY2VzDQoNCipGcm9tOiAqSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tPj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE0NCipUbzogKk1h cml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tPj4NCipDYzogKkFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzph ZGF3ZXNAZ29vZ2xlLmNvbT4+LCAibWF0YWtlLCBub3YiIDxub3ZAbWF0YWtlLmpwPG1haWx0bzpu b3ZAbWF0YWtlLmpwPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3Jn PG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCAiUGhpbCBIdW50IChJRE0pIiA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCipTdWJqZWN0OiAqUmU6 IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRp c3RpbmN0IFNFVCBpc3N1ZXINCg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90 cyBvZiBkaXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS4NCg0KT24gTW9uLCBKdW4g MTIsIDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PG1haWx0bzptc2N1cnRlc2N1QGdvb2ds ZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+PiB3cm90ZToNCg0KICAgIFRoYW5r cyBmb3IgdGhlIHBvaW50ZXIgRGljaywgdmVyeSBnb29kIHRpbWluZyA6LSkNCg0KICAgIFRoZSBp c3N1ZSBpcyBkZXNjcmliZWQgYnkgIjIuNy4gQ3Jvc3MtSldUIENvbmZ1c2lvbiIgYW5kIHRoZQ0K ICAgIG1pdGlnYXRpb24gaXMgaW4gIjMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2ZSBWYWxpZGF0 aW9uIFJ1bGVzIGZvcg0KICAgIERpZmZlcmVudCBLaW5kcyBvZiBKV1RzIiwgc3BlY2lmaWNhbGx5 ICJVc2UgZGlmZmVyZW50IHNldHMgb2YNCiAgICByZXF1aXJlZCBjbGFpbXMuLi4iLCAiVXNlIGRp ZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YNCiAgICBKV1RzLiIgYW5kICJVc2Ug ZGlmZmVyZW50IGlzc3VlcnMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzLiIuDQoNCiAgICBJ IHN0aWxsIHRoaW5rIHRoYXQgYSAidHlwZSIgY2xhaW0gd291bGQgYnJpbmcgYSBsb3Qgb2YgY2xh cml0eSBhbmQNCiAgICBzYWZldHkuDQoNCg0KICAgIE1hcml1cw0KDQogICAgT24gVGh1LCBKdW4g OCwgMjAxNyBhdCA5OjU5IFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20+DQogICAgPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNv bTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pj4gd3JvdGU6DQoNCiAgICAgICAgWWFyb24s IE1pa2UgYW5kIEkganVzdCBwdWJsaXNoZWQgYW4gQkNQIElEIGZvciBKV1QNCiAgICAgICAgaHR0 cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTY5MDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2VsZi0yRGlzc3VlZC5pbmZvXy0zRnAtM0QxNjkwJmQ9 RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hz aG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9YTdYdlo1alRidEEydmpmYUhJTWJ2RU9w U0JCbEJwZHNEa0lUWk1jVUlVUSZlPT4NCg0KICAgICAgICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0 IDk6MDIgUE0gQWRhbSBEYXdlcyA8YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29n bGUuY29tPg0KICAgICAgICA8bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNA Z29vZ2xlLmNvbT4+PiB3cm90ZToNCg0KICAgICAgICAgICAgSSB3YXMgaW5pdGlhbGx5IGEgZmFu IG9mIGtlZXBpbmcgU0VUUyB0byBiZSB2ZXJ5IHNpbWlsYXIgdG8NCiAgICAgICAgICAgIGlkIHRv a2VucyBidXQgSSBub3cgdGhpbmsgdGhpcyBpcyBhIGJldHRlciBwbGFuLg0KDQogICAgICAgICAg ICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgPG5vdkBtYXRha2Uu anA8bWFpbHRvOm5vdkBtYXRha2UuanA+DQogICAgICAgICAgICA8bWFpbHRvOm5vdkBtYXRha2Uu anA8bWFpbHRvOm5vdkBtYXRha2UuanA+Pj4gd3JvdGU6DQoNCiAgICAgICAgICAgICAgICArMSBl c3BlY2lhbGx5IGZvciAidHlwZSINCg0KICAgICAgICAgICAgICAgIDIwMTctMDYtMDkgMTA6MzIg R01UKzA5OjAwIFBoaWwgSHVudCAoSURNKQ0KICAgICAgICAgICAgICAgIDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pj46DQoNCiAgICAgICAgICAgICAg ICAgICAgKzENCg0KICAgICAgICAgICAgICAgICAgICBQaGlsDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgPiBPbiBKdW4gOCwgMjAxNywgYXQgNjoyOCBQTSwgTWFyaXVzIFNjdXJ0ZXNjdQ0KICAg ICAgICAgICAgICAgICAgICA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1 QGdvb2dsZS5jb20+DQogICAgICAgICAgICAgICAgICAgIDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQogICAgICAgICAg ICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoZXJlIHdlcmUgYSBjb3VwbGUg b2YgcHJvcG9zYWxzIG9uIGhvdyB0bw0KICAgICAgICAgICAgICAgICAgICBkaXN0aW5ndWlzaCBT RVRzIGZyb20gSWQgVG9rZW5zIGFuZCBBY2Nlc3MgVG9rZW5zIGluDQogICAgICAgICAgICAgICAg ICAgIHN1Y2ggYSB3YXkgdGhhdCBuYWl2ZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3QNCiAgICAg ICAgICAgICAgICAgICAgY29uZnVzZSBvbmUgZm9yIHRoZSBvdGhlciBhbmQgb3BlbiB1cCBzZWN1 cml0eQ0KICAgICAgICAgICAgICAgICAgICB2dWxuZXJhYmlsaXRpZXMuDQogICAgICAgICAgICAg ICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoZXJlIGlzIGFsc28gYW5vdGhlciBp bXBvcnRhbnQgcmVxdWlyZW1lbnQ6IHRoZQ0KICAgICAgICAgICAgICAgICAgICBTRVQgaXNzdWVy IGluIHNvbWUgY2FzZXMgbXVzdCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUNCiAgICAgICAgICAgICAg ICAgICAgInN1YiIgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcgU0VU cw0KICAgICAgICAgICAgICAgICAgICB0byBhbiBJZFAuDQogICAgICAgICAgICAgICAgICAgICA+ DQogICAgICAgICAgICAgICAgICAgICA+IFdpdGggdGhlc2UgcmVxdWlyZW1lbnRzIGluIG1pbmQg SSBwcm9wb3NlIHRoZQ0KICAgICAgICAgICAgICAgICAgICBmb2xsb3dpbmc6DQogICAgICAgICAg ICAgICAgICAgICA+IC0gYm90aCAic3ViIiBhbmQgImlzcyIgdG8gYmUgZGVmaW5lZCBhdCB0aGUg ZXZlbnQNCiAgICAgICAgICAgICAgICAgICAgbGV2ZWwNCiAgICAgICAgICAgICAgICAgICAgID4g LSAiaXNzIiBhdCBldmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBsZXZlbCBjYW4NCiAgICAgICAg ICAgICAgICAgICAgYmUgZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAgICA+IC0gImlzcyIg YW5kICJzdWIiIGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQNCiAgICAgICAgICAgICAg ICAgICAgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQNCiAgICAgICAgICAgICAgICAgICAg ID4gLSAic3ViIiBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBTRVQNCiAgICAgICAg ICAgICAgICAgICAgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFz ZSBub3RlDQogICAgICAgICAgICAgICAgICAgICJzaG91bGQiIGFuZCBub3QgIm11c3QiDQogICAg ICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoaXMgc29sdXRpb24g YWxzbyBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQNCiAgICAgICAgICAgICAgICAgICAg ZGVmaW5lIGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltcw0KICAgICAgICAg ICAgICAgICAgICByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFu ZA0KICAgICAgICAgICAgICAgICAgICBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUgYXQg dGhlIGV2ZW50IGxldmVsDQogICAgICAgICAgICAgICAgICAgIHRoZXJlIHdpbGwgYmUgbm8gY29s bGlzaW9ucyBvciBhbWJpZ3VpdHkuDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAg ICAgICAgICAgICA+IEFub3RoZXIgcHJvcG9zYWwgKHdoaWNoIEkgc3VwcG9ydGVkKSB3YXMgdG8N CiAgICAgICAgICAgICAgICAgICAgZGVmaW5lIGEgY29tcG9zaXRlICJhdWQiIGNsYWltLiBUaGlz IGlzIG5vdCBzb2x2aW5nDQogICAgICAgICAgICAgICAgICAgIHRoZSByZXF1aXJlbWVudCBmb3Ig YSBkaXN0aW5jdCAgU0VUIGlzc3Vlci4gQWxzbywNCiAgICAgICAgICAgICAgICAgICAgaGF2aW5n IHRoZSBzYW1lIGNsYWltIG5hbWUgaGF2aW5nIGRpZmZlcmVudCBzeW50YXgNCiAgICAgICAgICAg ICAgICAgICAgaW4gZGlmZmVyZW50IHRva2VuIHR5cGVzIGNvdWxkIGxlYWQgdG8gY29uZnVzaW9u Lg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBBbmQgeWV0 IGFub3RoZXIgcHJvcG9zYWwgd2FzIHRvIGludHJvZHVjZSBhIG5ldw0KICAgICAgICAgICAgICAg ICAgICBjbGFpbSBmb3IgSldUcyB0aGF0IGRlZmluZXMgYSAidHlwZSIuIFRoaXMgaXMgbm90DQog ICAgICAgICAgICAgICAgICAgIHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwgYW5kIGl0IGFs c28gaXMgbm90DQogICAgICAgICAgICAgICAgICAgIHNvbHZpbmcgdGhlIGRpc3RpbmN0IGlzc3Vl ciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbmsNCiAgICAgICAgICAgICAgICAgICAgdGhpcyBpcyBz b21ldGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5DQogICAgICAgICAgICAgICAg ICAgIGNvbnNpZGVyLg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAg ICAgPiBUaG91Z2h0cz8NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAg ICAgID4gTWFyaXVzDQoNCiAgICAgICAgICAgICAgICAgICAgID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAgICAgICAgID4gSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgICAgICA+IElkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAg ICAgICAgICAgICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lD QWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJp UnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPUptdXV0Qng0REFQcDc0QVVM Y3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmcz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlL T0NkMG14UFFGSkxoeFdJJmU9DQoNCiAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAgICAgICAgSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgICAgIElkLWV2ZW50QGlldGYub3Jn PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRw a0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdr Jm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pz c0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgICAgICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAg ICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgICAgIElkLWV2ZW50 QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdt WnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAg ICAgLS0NCiAgICAgICAgICAgIEFkYW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHxhZGF3 ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+DQogICAgICAgICAgICA8bWFp bHRvOmFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4+IHwrMSA2NTAt MjE0LTI0MTA8dGVsOiUyQjElMjA2NTAtMjE0LTI0MTA+DQogICAgICAgICAgICA8dGVsOig2NTAp JTIwMjE0LTI0MTA8dGVsOiUyODY1MCUyOSUyMDIxNC0yNDEwPj4NCg0KICAgICAgICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAg IElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVu dCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdK UEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVn TEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgLS0NCiAgICAgICAgU3Vic2Ny aWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1E d01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJt NWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNo bVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGho MVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFpbCBsaXN0IHRvDQogICAgICAgIGxlYXJuIGFib3V0 IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQoNClN1YnNjcmliZSB0byB0aGUg SEFSRFRXQVJFIDxodHRwOi8vaGFyZHR3YXJlLmNvbS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJnM9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhN WUJlclY4MCZlPT4+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtp bmcgb24hDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhD c0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3 VG1HTVNXV3MmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29N VTdUbUdNU1dXcyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZy PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQ S0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdM RDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCg0KSWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2 ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50DQo= --_000_370B5025BD044B059FFDD8850230BBBFamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KcC5tOTA5 NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGxpLm05MDk0MDg5MjM5NjY4NTcwMzEy bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFw aA0KCXttc28tc3R5bGUtbmFtZTptOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgc3BlYyBzYXlzIHRoYXQgdGhlIGV2ZW50cyBj bGFpbSBTSE9VTEQgTk9UIGJlIHVzZWQgdG8gZXhwcmVzcyBtdWx0aXBsZSBsb2dpY2FsIGV2ZW50 cy4gSWYgaXTigJlzIGFsc28gbm90IHVzZWQgdG8gZXhwcmVzcyBldmVudHMgZnJvbSBkaWZmZXJl bnQgcHJvZmlsZXMgdGhhdCBjb3JyZXNwb25kIHRvDQogdGhlIHNhbWUgbG9naWNhbCBldmVudCAo ZS5nLiBhbiBPSURDIGJhY2tjaGFubmVsIGxvZ291dCBldmVudCBhbG9uZ3NpZGUgYSBoeXBvdGhl dGljYWwgUklTQyBsb2dvdXQgZXZlbnQpLCB0aGVuIEnigJltIG5vdCBzdXJlIHdoYXQgdXNlIGNh c2UgdGhhdCBsZWF2ZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBvbmUgU0VULjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZGVudGl0eSBT ZXJ2aWNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtQaGlsIEh1bnQgKElETSkmcXVv dDsgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIEp1bmUgMjEsIDIwMTcgYXQgMjoxMiBQTTxicj4NCjxiPlRvOiA8L2I+Sm9obiBCcmFkbGV5 ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O1JpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDtyaWNoYW5uYUBhbWF6b24uY29tJmd0OywgSGVu ayBCaXJraG9seiAmbHQ7aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSZndDssIEp1c3Rp biBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDssIE1hcml1cyBTY3VydGVzY3UgJmx0O21z Y3VydGVzY3VAZ29vZ2xlLmNvbSZndDssIFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdt YWlsLmNvbSZndDssIE1pY2hhZWwgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSZndDssDQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nl c3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZXBhcmF0ZSBv ciBjb21iaW5lZCBtYXkgYmUgZXZvbHZpbmcuIE1pa2Ugd2FudHMgdG8ga2VlcCB0aGUgY3VycmVu dCBiYWNrY2hhbm5lbCBsb2dvdXQgdmVyeSBuYXJyb3dseSBzY29wZWQuIEhlIHN1Z2dlc3RlZCBy aXNjIGRlZmluZSBpdHMgb3duIGR1cGxpY2F0ZSBkZWZpbml0aW9ucyBhbmQgbWVhbmluZ3MuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgbGVh ZHMgbWUgdG8gYmVsaWV2ZSB3ZSB3aWxsIGhhdmUgbXVsdGktdHlwZSBldmVudHMgaW4gcHJhY3Rp Y2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlc3Npb24g Y2FuY2VsbGF0aW9uIGNhbiBvY2N1ciBmb3IgbWFueSByZWFzb25zLiBPbmUgb2YgdGhlIGRpZmZl cmVudGlhdG9ycyB3ZSBoYWQgdHJpZWQgdG8gbWFrZSB3YXMgYW4gYXNzdW1wdGlvbiB0aGF0IHVz ZXIgaW5pdGlhdGVkIGV2ZW50cyB3b3VsZCBiZSBwYXJ0IG9mIGNvbm5lY3QuIFJpc2sgd291bGQg Y292ZXIgdmFyaWF0aW9ucyB0aGF0IGRyaXZlIG9mZiBvZiByaXNrIGNhbGN1bGF0aW9ucyBsaWtl DQogcGFzc3dvcmQgcmVzZXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBhbHNvIHNpZ25vdXQgZXZlbnRzIGF0IHJwJ3MgdG8gbGV0 IHRoZSBPUCBrbm93LiBUaGVzZSBhcmUgbm90IGNvbW1hbmRzIGJ1dCBub3RpZmljYXRpb24gdGhh dCBhIHJlc291cmNlIHNlc3Npb24gaXMgY2FuY2VsbGVkLiBJT1cgc2luZ2xlIHNpZ24gb3V0IG5v dCBleHBlY3RlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVuIDIxLCAyMDE3LCBhdCAxOjU4IFBNLCBKb2huIEJy YWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0 Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBhcmUgb25seSBh bGxvd2luZyBzZXQgbWVzc2FnZXMgZm9ybSB0aGUgc2FtZSBmYW1pbHkgdGhhdCBhZ3JlZSBvbiB0 b3AgbGV2ZWwgY2xhaW1zLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PdGhlcndpc2UgdGhlcmUgY2FuIGJlIG5vIHRvcCBsZXZlbCBjbGFpbXMgYW5kIHdl IGFyZSByZWFsbHkgZGVmaW5pbmcgYSBhbHRlcm5hdGl2ZSBmb3JtYXQgdG8gSldUIGluIHNvbWUg d2F5cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gSnVuIDIxLCAyMDE3LCBhdCAzOjU0IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iPnJpY2hhbm5h QGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkkgYWdyZWUgd2l0aCBKb2huIHRoYXQgdGhlIEpXVCB0eXBlIGNvbmZ1c2lvbiBwcm9ibGVtIGFu ZCB0aGUgU0VUIHN1YiBwcm9ibGVtIGNhbiBhbmQgc2hvdWxkIGJlIGRpc2N1c3NlZCBzZXBhcmF0 ZWx5LiBUaGUgc2VjZXZlbnRzIFdHIGlzIHByb2JhYmx5DQogbm90IHRoZSByaWdodCBzZXR0aW5n IHRvIGRpc2N1c3MgdGhlIGZvcm1lci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5NeSBjb25jZXJuIHdpdGggdGhlIHN1YiBjbGFpbSBpcyB0aGF0IHR3byBwcm9maWxlcyBt YXkgZGljdGF0ZSBjb25mbGljdGluZyBzZW1hbnRpY3MgKGUuZy4gUHJvZmlsZSBBIHNheXMgaXTi gJlzIGEgcGhvbmUgbnVtYmVyLCBQcm9maWxlIEIgc2F5cyBpdOKAmXMNCiBhbiBlbWFpbCBhZGRy ZXNzKS4gSWYgdGhlc2UgcHJvZmlsZXMgZG9u4oCZdCBwcm92aWRlIGFuIGFsdGVybmF0ZSB3YXkg dG8gZGVjbGFyZSBzdWJqZWN0IG9mIHRoZWlyIGV2ZW50cywgdGhlbiB0aGV5IGNhbm5vdCBiZSBw cmVzZW50IHdpdGhpbiB0aGUgc2FtZSB0b2tlbi4gVGhpcyBpbmNvbXBhdGliaWxpdHkgdHJhcCBz ZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGVhc2lseSBtaXNzZWQgYnkgZ3JvdXBz IHByb2ZpbGluZyBTRVQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4tLSZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Kb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdq dGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNk YXksIEp1bmUgMjEsIDIwMTcgYXQgMTozOSBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+WWFyb24gU2hlZmZlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+eWFyb25mLmlldGZAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9iPkp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVy QG1pdC5lZHUiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7LCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8 YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIj5tc2N1cnRlc2N1QGdvb2dsZS5j b208L2E+Jmd0OywgQW5uYWJlbGxlIFJpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDssDQogUGhpbCBIdW50ICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPiZndDssIE1pY2hhZWwgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7LCBJ RCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5v cmciPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDssIEhlbmsNCiBCaXJraG9seiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiPmhlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBzb2x1 dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vl cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPkluIHRoZSBlbnZlbG9wZSB0eXAgaXMgYSBtZWRpYS9taW1l IHR5cGUuICZuYnNwO1JlZ2lzdGVyaW5nIGFwcGxpY2F0aW9uL2lkdCYjNDM7and0IGlmIHdlIHJl Z2lzdGVyIGp3dCBhcyBhIHN0cnVjdHVyZWQgbmFtZSBzdWZpeC4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PlVzaW5nIHRoZSBjdHkgaXMgYWxzbyBwb3NzaWJsZS4gJm5ic3A7IEkgbmVlZCB0byB0aGluayBh Ym91dCB3aGF0IGlzIGJldHRlciBidXQgd2UgY2FuIGFncmVlIG9uIGEgY29udmVudGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Tm90IGV2ZXJ5dGhpbmcgaXMgZ29pbmcgdG8gYmUgYSBz ZXQgdG9rZW4gbGlrZSBub3QgZXZlcnkgSldTIGlzIGEgSldULjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PklmIHdlIGFyZSBnb2luZyB0byBkZWZpbmUgcHJvY2Vzc2luZyBydWxlcyB0byBzdG9wIGNvbGxp c2lvbnMgYW5kIGNvbmZ1c2lvbiBhcm91bmQgSldUIGZvciBkaWZmZXJlbnQgcHVycG9zZXMsIHdl IHNob3VsZCBqdXN0IHN0YXJ0IHVzaW5nIHRoZSB0eXAgcGFyYW1ldGVyIGJhc2VkIG9uIHRoZSBl eGlzdGluZyBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkluIGdlbmVyYWwgY29udGVudCBzbmlm ZmluZyBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIG9wdGlvbiBldmVudHVhbGx5IGdldHMgeW91 IGludG8gdHJvdWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGFtIG5vdCBjb252aW5jZWQgdGhh dCBmb3JjaW5nIHRoZXJlIHRvIGJlIG5vIHN1YiBhdCB0aGUgdG9wIGxldmVsIGlzIGEgZ29vZCBp ZGVhLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JdCBpcyBub3QgdGhlIHdheSB3ZSBzaG91 bGQgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIFNFVCBhbmQgaWRfdG9rZW5zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5J ZiBzdWIgaXMgbm90IGFsbG93ZWQgYXQgdGhlIHRvcCBsZXZlbCBwZW9wbGUgd2lsbCBkbyBub24g U0VUIEpXVCBmb3IgdGhpbmdzIHdoZXJlIHRoZSBzdWJqZWN0IGlzIHNjb3BlZCB0byB0aGUgaXNz IG9mIHRoZSB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIHRoaW5rIGRlZmluaW5nIHN1YiB0 byBiZSBwYXJ0IG9mIHRoZSBldmVudCBmb3IgY2FzZXMgd2hlcmUgdGhlIHN1YiBpcyBzY29wZWQg ZGlmZmVyZW50bHkgZnJvbSB0aGUgaXNzdWVyIG9mIHRoZSB0b2tlbiBpcyBmaW5lLCBidXQgc2hv dWxkIG5vdCBiZSByZXF1aXJlZCBmb3IgYWxsIGV2ZW50IHR5cGVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPkkgdGhpbmsgd2Ugc2hvdWxkIHNvbHZlIHRoZSBjb25mdXNpb24gaXNzdWUgc2VwYXJhdGVs eSBmcm9tIHRoZSBzdWIgaXNzdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+U29ycnkgSSBhbSBhdCBD SVMgc28gdHJ5aW5nIHRvIGNhdGNoIHVwIG9uIGxpc3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkpv aG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gSnVuIDE3LCAyMDE3LCBhdCAzOjQ1IFBNLCBZ YXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlNvIHRvIHN1bW1hcml6ZSB3aGF0IEknbSBzZWVpbmcg b24gdGhpcyB0aHJlYWQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+RXZlcnlib2R5IGFncmVlcyB3aXRo IE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmljIHJ1bGVzIGZvciAmcXVvdDtz dWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0aGF0IGNhbiBiZSBkZWZpbmVkIGluIHRoZSBT RVQgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BbG1vc3QgZXZlcnlib2R5IGFncmVlcyBvbiBh IGxvbmctdGVybSAmcXVvdDt1c2FnZSZxdW90OyBjbGFpbSAoJnF1b3Q7dHlwZSZxdW90OyBpcyB0 YWtlbikgdGhhdCBzaG91bGQgYmUgZGVmaW5lZCBlbHNld2hlcmUsIGUuZy4gaW4gdGhlIEpXVCBC Q1AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+RGlkIEkgbWlzcyBhbnl0aGluZz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5CeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAmcXVvdDt1c2FnZSZxdW90OyBjbGFp bSwgd2UgbmVlZCB0byBhbHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBp cyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOyZuYnNwOyZuYnNwOyBZYXJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5PbiAxNS8wNi8xNyAyMjowOCwgSnVzdGluIFJpY2hl ciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+JiM0MzsxIHRvIHRoaXMgYXMg d2VsbC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+T24gSnVuIDE1 LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86 bXNjdXJ0ZXNjdUBnb29nbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRl c2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiYjNDM7MSB0 byB3aGF0IEFubmFiZWxsZSBzYWlkLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+QWxzbywgTWlrZSB5b3UgYXJlIG1pc3NpbmcgdGhl IG90aGVyIHJlcXVpcmVtZW50LCBmb3IgUlBzIHRvIHNlbmQgZXZlbnRzIHRvIGFuIElkUC4gVGhl IGlzcyYjNDM7c3ViIHBhaXIgYXQgdGhlIHRvcCBsZXZlbCBpcyBicm9rZW4gaW4gdGhpcyBjYXNl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5NYXJpdXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPk9uIFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiYjNDM7MTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fOTA5NDA4OTIzOTY2ODU3MDMxMkFwcGxlTWFp bFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1fOTA5NDA4OTIzOTY2ODU3MDMxMkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlBoaWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gSnVuIDE0LCAyMDE3LCBhdCA1OjI1IFBNLCBSaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpv bi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5u YUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWtlLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllvdXIgZXhwbGFuYXRp b24gZm9yIHdoeSB0aGlzIGlzIGEgbm9uLXByb2JsZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBl ZmZlY3RzIG9mIGVsZW1lbnRzIG9mIE9wZW5JRCBDb25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWdu ZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4NCiBBcyBhIHJlc3VsdCwgSSBzZWUgc2V2ZXJhbCBpc3N1 ZXMgd2l0aCBpdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtOTA5 NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUN CiBjYWxsZXIgb2YgdGhlIFRva2VuIEVuZHBvaW50IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQgY2Fu IGJlIGNlcnRhaW4gdGhhdCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRv a2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRv IGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92ZW5hbmNlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjIuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5BbnkNCiBmdXR1cmUgSUQgVG9rZW4gZGlzdHJpYnV0aW9uIG1ldGhvZCBu ZWVkcyB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYWdhaW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Obw0KIG90aGVyIHBy b2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0aGUgJnF1b3Q7bm9uY2XigJ0gY2xhaW0uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjQuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UaGlzDQogaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVy IEpXVCBwcm9maWxlIHRoYXQgY2FyZXMgYWJvdXQgZGlzYW1iaWd1YXRpb24gaGFzIHRvIGludmVu dCBpdHMgb3duIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5hbWlu ZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBoYXBw ZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVhc3Vy ZQ0KIGFnYWluc3QgdGhlc2Ugcmlza3MuIFlvdSBicm91Z2h0IHVwIEpXVCBsaWJyYXJpZXM6IGEg Z2VuZXJhbCBzb2x1dGlvbiBhY3R1YWxseSBtYWtlcyBpdCBlYXNpZXIgdG8gdXNlIGNvbW1vbiBs aWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBBIOKAnHVzYWdlLWF3YXJl4oCdIEpXVCBsaWJyYXJ5 IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlvbiBmb3IgYW55IEpXVCBwcm9maWxlLCB3aGVyZWFz IHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBwcm9maWxlIHdvdWxkDQogcmVxdWlyZSB1bmlxdWUg bG9naWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4tLSZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J ZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgJmx0Ozxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYg UE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9iPk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1 QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5t c2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90O1JpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1h em9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hh bm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0 OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7LA0K IEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1 bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVu ay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5S ZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQg ZGlzdGluY3QgU0VUIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+WW914oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKA nS4mbmJzcDsgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQg YXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2Fu IGFuZCBzaG91bGQNCiBiZSBzaW1wbGUgY29tcGxleCwgd2l0aG91dCBkYXRhIHNob3dpbmcgdGhl cmXigJlzIGFueSBuZWVkIHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGlu IHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQg d2UgYWN0dWFsbHkgZXZlbiBoYXZlLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlz aGVkDQogdGhhdCBpdOKAmXMgaW1wb3NzaWJsZSBmb3IgYSBTRVQgdG8gYmUgY29uZnVzZWQgZm9y IGFuIElEIFRva2VuIOKAkyBzZWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lkLTJEZXZl bnRfY3VycmVudF9tc2cwMDQyOC5odG1sJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0Rm dC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1lS0xUUVBtWXJWM1RoZkRibjkwU0NzNTVVUk9UUGluX2xn YzZSZHI1WG93JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVu dC9tc2cwMDQyOC5odG1sPC9zcGFuPjwvYT4uJm5ic3A7DQogSWYgcGVvcGxlIGhhdmUgZGF0YSBz aG93aW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSB3aXRoIHNwZWNpZmljIGtpbmRzIG9mIEFjY2Vz cyBUb2tlbnMgb3Igb3RoZXIgcmVhbCBKV1QgZGVwbG95bWVudHMsIHBsZWFzZSBwcm92aWRlIHNw ZWNpZmljcywgc28gdGhhdCB3ZSBjYW4gdXNlIHRoYXQgZGF0YSB0byBpbmZvcm0gYXBwcm9wcmlh dGUgZW5naW5lZXJpbmcgY2hvaWNlcyBvbiBvdXIgcGFydC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGUgcHJvcG9zZWQg4oCcc29sdXRpb25z4oCdLCBz dWNoIGFzIHByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIGluIHRoZSBub3JtYWwgd2F5 LCBvciByZXF1aXJpbmcgYSB0eXBlIGNsYWltLCB3b3VsZCBtYWtlIHByZXZpb3VzbHkgc2ltcGxl IHRoaW5ncyB1bm5lY2Vzc2FyaWx5DQogY29tcGxleC4mbmJzcDsgWWVzLCB0aGVuIHRoZSByZXN1 bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ug b2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1c2Vk LCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuJm5ic3A7IFRoZSBtb3JlIHVud2ll bGR5IHdlIG1ha2UgaXQgdG8gdXNlIFNFVHMsIHRoZSBtb3JlIGxpa2VseSBkZXZlbG9wZXJzIGFy ZSB0bw0KIGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuJm5ic3A7IEtlZXBp bmcgaXQgc2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uJm5ic3A7IFN0YW5kYXJkcyBhcmUg b25seSB1c2VmdWwgaWYgdGhleSBhcmUgYWN0dWFsbHkgdXNlZC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JZC1ldmVudA0KIFs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGU8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgSnVuZSAxMywgMjAxNyA1OjMzIFBN PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5NYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNj dXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDs8YSBo cmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9m ZXIuZGU8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0Ozxh IGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVz aW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjogY2FuIHlvdSBleHBs YWluIHdoYXQgeW91IG1lYW4gYnkg4oCcaW50ZW5k4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkg dGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3b3VsZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVu c2lvbjogYSBtdWx0aS12YWx1ZWQgcHJvcGVydHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQg cHVycG9zZQ0KIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1heSByZWZlciB0byB3 aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNjZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0 byBpdCBpbiBzb21lIGNvbnRleHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5p ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mIE1h cml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdv b2dsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwgSnVuZSAxMywgMjAxNyBh dCAxMTowNSBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+SGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsu Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5JRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2 ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3Qg U0VUIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPk9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHog Jmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPkFuZCBhIDJu ZCBxdWVzdGlvbi48YnI+DQo8YnI+DQpXaGF0IHNlbWFudGljcyB3b3VsZCAmcXVvdDt1c2FnZSZx dW90OyBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICZxdW90O2ludGVuZCZx dW90OywgJnF1b3Q7YXVkaWVuY2UmcXVvdDssIGFuZCAmcXVvdDtzY29wZSZxdW90Oz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+JnF1b3Q7YXVkJnF1b3Q7IChhdWRp ZW5jZSkgc3BlY2lmaWVzIHRoZSB0YXJnZXQgY2xpZW50LCBidXQgbm90IHRoZSBpbnRlbmRlZCB1 c2FnZSAoYWNjZXNzIHRva2VuIHRvIGF1dGhvcml6ZSByZXNvdXJjZSBhY2Nlc3Mgb3IgU0VUIHRv IGNvbW11bmljYXRlIGEgc2VjdXJpdHkgZXZlbnQ/KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPiZxdW90O3Njb3BlJnF1b3Q7IGlzIG5vdCB1c2VkIGJ5IFNFVC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JIGRvbid0IGtub3cgd2hhdCBkbyB5b3UgbWVhbiBi eSAmcXVvdDtpbnRlbmQmcXVvdDsgKG9yIGludGVudCk/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxi cj4NCjxicj4NCkhlbms8YnI+DQo8YnI+DQpPbiAwNi8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoYW5rcyBmb3IgcHV0dGlu ZyB0aGlzIHRvZ2V0aGVyITxicj4NCjxicj4NCkkgdGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVy ZW50IGluIDMuOSBhcmUgZmxhd2VkOjxicj4NCjxicj4NCsK3V2UgY2Fu4oCZdCBndWFyYW50ZWUg dGhhdCBldmVyeSB0eXBlIG9mIEpXVCB3aWxsIGhhdmUgYSBtdXR1YWxseSBleGNsdXNpdmUgc2V0 IG9mIHZhbGlkIGNsYWltcyBhbmQvb3IgaGVhZGVyIHBhcmFtZXRlcnMsIGFuZCBlbmZvcmNpbmcg dGhpcyByZXF1aXJlcyBhIOKAnGZhaWwgb24gYW4gdW5yZWNvZ25pemVkIGNsYWlt4oCdIGFwcHJv YWNoIHRvIGVuc3VyZSB0aGF0IEpXVHMgZnJvbSBzb21lIGZ1dHVyZSBzcGVjIGNhbuKAmXQgYmUg bWlzdGFrZW4gZm9yIEpXVHMNCiBmcm9tIGEgY3VycmVudCBzcGVjLjxicj4NCjxicj4NCsK3SXQg aXMgdW5yZWFsaXN0aWMgdG8gZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKA nGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0 aGVyIG1hbmRhdGVkIGJ5IHRoZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3Jl IHRoaXMgYmVjYXVzZSBtYW5hZ2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4g ZGlmZmVyZW50IGtleXMuPGJyPg0KPGJyPg0KwrdEaXR0byBmb3Ig4oCcYXVk4oCdIGFuZCDigJxp c3PigJ0gY2xhaW1zLjxicj4NCjxicj4NCiYjNDM7MSBmb3IgYSDigJx0eXBl4oCdIG9yIOKAnHVz YWdl4oCdIGNsYWltL2hlYWRlciBwYXJhbWV0ZXIuPGJyPg0KPGJyPg0KLS08c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KQW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbjxicj4NCjxicj4NCklkZW50aXR5IFNlcnZpY2VzPGJyPg0KPGJyPg0K KkZyb206ICpJZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0 ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48 L2E+Jmd0Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE08YnI+ DQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNj dXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KKkNjOiAqQWRhbSBEYXdlcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhd2VzQGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDss ICZxdW90O21hdGFrZSwgbm92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5q cCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm5vdkBtYXRha2Uu anA8L3NwYW4+PC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nDQogTGlzdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssICZxdW90O1BoaWwg SHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9y YWNsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZlbnRdIHNv bHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNz dWVyPGJyPg0KPGJyPg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBvZiBk aXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS48YnI+DQo8YnI+DQpPbiBNb24sIEp1 biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZn dDsmZ3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHRoZSBw b2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICZxdW90OzIuNy4gQ3Jvc3MtSldUIENvbmZ1c2lv biZxdW90OyBhbmQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBtaXRpZ2F0aW9uIGlzIGluICZxdW90 OzMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2ZSBWYWxpZGF0aW9uIFJ1bGVzIGZvcjxicj4NCiZu YnNwOyAmbmJzcDsgRGlmZmVyZW50IEtpbmRzIG9mIEpXVHMmcXVvdDssIHNwZWNpZmljYWxseSAm cXVvdDtVc2UgZGlmZmVyZW50IHNldHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IHJlcXVpcmVkIGNs YWltcy4uLiZxdW90OywgJnF1b3Q7VXNlIGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQga2lu ZHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IEpXVHMuJnF1b3Q7IGFuZCAmcXVvdDtVc2UgZGlmZmVy ZW50IGlzc3VlcnMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzLiZxdW90Oy48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IEkgc3RpbGwgdGhpbmsgdGhhdCBhICZxdW90O3R5cGUmcXVvdDsgY2xh aW0gd291bGQgYnJpbmcgYSBsb3Qgb2YgY2xhcml0eSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IHNh ZmV0eS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE1hcml1czxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjU5IFBNLCBEaWNrIEhhcmR0ICZs dDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+ PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRp Y2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFyb24sIE1pa2UgYW5kIEkganVzdCBwdWJsaXNo ZWQgYW4gQkNQIElEIGZvciBKV1Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3NlbGYtMkRp c3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdK eFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQt MDBZXzN6Um9haTExNWMmYW1wO3M9YTdYdlo1alRidEEydmpmYUhJTWJ2RU9wU0JCbEJwZHNEa0lU Wk1jVUlVUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkwPC9zcGFuPjwvYT48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBN IEFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmFkYXdlc0Bnb29nbGUuY29tPC9z cGFuPjwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SSB3YXMgaW5pdGlhbGx5IGEgZmFuIG9mIGtlZXBpbmcgU0VUUyB0byBiZSB2ZXJ5IHNpbWlsYXIg dG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpZCB0b2tl bnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3 IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgJmx0OzxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpw IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bm92QG1hdGFrZS5q cDwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm5vdkBtYXRha2UuanA8L3NwYW4+PC9hPiZn dDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxIGVzcGVjaWFsbHkgZm9yICZxdW90O3R5cGUm cXVvdDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDIwMTctMDYtMDkgMTA6MzIgR01UJiM0MzswOTowMCBQaGlsIEh1bnQg KElETSk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNv bTwvc3Bhbj48L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyZndDs6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj NDM7MTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaGlsPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgT24gSnVuIDgsIDIwMTcsIGF0IDY6MjggUE0sIE1hcml1cyBTY3Vy dGVzY3U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1 cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1z Y3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSB3ZXJl IGEgY291cGxlIG9mIHByb3Bvc2FscyBvbiBob3cgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlzdGlu Z3Vpc2ggU0VUcyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBpbjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGNvbmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2Vj dXJpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdnVsbmVyYWJpbGl0aWVzLjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUgaXMgYWxzbyBh bm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNFVCBp c3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmcXVvdDtzdWImcXVvdDsgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQ IHNlbmRpbmcgU0VUczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBhbiBJZFAuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBXaXRoIHRoZXNlIHJl cXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9sbG93 aW5nOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gYm90aCAmcXVvdDtzdWImcXVvdDsg YW5kICZxdW90O2lzcyZxdW90OyB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1 b3Q7IGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O2lz cyZxdW90OyBhbmQgJnF1b3Q7c3ViJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJl bnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O3N1YiZxdW90OyBzaG91bGQgTk9UIGJlIHBy ZXNlbnQgYXQgdGhlIHRvcCBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2ZWwgKHRoaXMgc29sdmVz IHRoZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFzZSBub3RlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90 O3Nob3VsZCZxdW90OyBhbmQgbm90ICZxdW90O211c3QmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoaXMgc29sdXRpb24gYWxz byBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5l IGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltczxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFuZDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxl dmVsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJlIHdpbGwgYmUgbm8gY29sbGlzaW9ucyBvciBhbWJp Z3VpdHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGRlZmluZSBhIGNvbXBvc2l0ZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0uIFRo aXMgaXMgbm90IHNvbHZpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHJlcXVpcmVtZW50IGZvciBh IGRpc3RpbmN0Jm5ic3A7IFNFVCBpc3N1ZXIuIEFsc28sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGhhdmlu ZyB0aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGluIGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi48 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBhICZxdW90O3R5cGUmcXVvdDsu IFRoaXMgaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVy bSwgYW5kIGl0IGFsc28gaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNvbHZpbmcgdGhlIGRpc3Rp bmN0IGlzc3VlciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbms8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhp cyBpcyBzb21ldGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGNvbnNpZGVyLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgVGhvdWdodHM/PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdY enVhNm1pUmlIcVdnZnhxbWcmYW1wO3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBt eFBRRkpMaHhXSSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJt NWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERB UHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3 VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmYW1wO2U9PC9zcGFuPjwvYT48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJt NWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQ S0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRY OXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZC1ldmVudDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklk LWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBF aXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZ XzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdN U1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBZGFtIERhd2VzIHwgU3IuIFBy b2R1Y3QgTWFuYWdlciB8PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhd2VzQGdvb2dsZS5jb208L3Nw YW4+PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhd2VzQGdvb2dsZS5jb208L3NwYW4+PC9h PiZndDsgfDxhIGhyZWY9InRlbDolMkIxJTIwNjUwLTIxNC0yNDEwIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+JiM0MzsxIDY1MC0yMTQtMjQxMDwvc3Bhbj48L2E+ PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhy ZWY9InRlbDolMjg2NTAlMjklMjAyMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnRlbDooNjUwKSUyMDIxNC0yNDEwPC9zcGFuPjwvYT4mZ3Q7PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1l dmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm YW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1V c2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pz c0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0tPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJzY3JpYmUgdG8gdGhl IEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3 ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGho MVRPclFPVVgyWE1ZQmVyVjgwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvc3Bhbj48L2E+Jmd0Ow0KIG1haWwg bGlzdCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFybiBhYm91dCBwcm9q ZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS08c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KU3Vic2Ny aWJlIHRvIHRoZSBIQVJEVFdBUkUgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9aTc1VXc4YWVoWXZscEla Tkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vaGFyZHR3YXJlLmNvbS88L3NwYW4+PC9hPiZn dDsNCiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxi cj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3 NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5 dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklk LWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGll dGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJL Q1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xO S2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkx MTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2 ZW50QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3 SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFt cDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNs ajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NL RlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQt MkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZ VHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRD X2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMm YW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT08 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFu PjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+SWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_370B5025BD044B059FFDD8850230BBBFamazoncom_-- From nobody Wed Jun 21 14:59:23 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CD8127868 for ; Wed, 21 Jun 2017 14:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IENn8Q3Qghp for ; Wed, 21 Jun 2017 14:59:17 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E31127369 for ; Wed, 21 Jun 2017 14:59:17 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id b205so10994895itg.1 for ; Wed, 21 Jun 2017 14:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LAS7vD4Fz/VTP6/kYtdXmUyzFDF41krhdjkHpSd5BuI=; b=SUrtdhDwHIndzJ/+RHCadHo7KGBLqhjA861sRa6evoQK89tV/7Q5DjtZ7i8Yr1QWcn yx91AAenOMZhAC9QoqHMe9gbICYvXnw1gcpU06BrHHihiIsp3FGjbdhylbJ2IWU1Kozo 2ZWdv1mxm7NnGqcyyYIOqAqjjd8ft0Kt5cMvINDGEuyPtkB2xdz3hD2QyNzQzv8qPrh+ qp8Bwd/bPrCRK0Fw1ktCp8zPzSY1PGI7wuHlxl4nuq3gClfxZV6JuHiSP3ws2cy17eBc uPKQIT0smLjAxm+zvPe459jMVEYO0eBFP3ChlBxjSI+JJf0NHiW4Omdd/i29Gcf+pRt4 2w7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LAS7vD4Fz/VTP6/kYtdXmUyzFDF41krhdjkHpSd5BuI=; b=hO9MERBLYv7BIa8lH5YHoOVbu0CTaVjBkla73WJaMQgWMSa1NpkF78lBr4CetypK7C GwkfdNpch4ASwQphuGhyzQQfFh/mk03olCcFxiMk0Th26HpzqGdSOSVRNbfzUPsmw+1q WvmcewXxkt7zGQiF/DqkOWhEK9kApLc0UWNFrlJ2JxE7XQ1W8KEjQ80G9x/ZVvjPYUOO U53s4vf88fkah2TOJTBumwnpehrZ7OcnxgXAi2argpPXb7x0cRAhrVwf282KdPlTmPEg e/A3hPMavZO7lnjD2nveTdQOkIBpK9DmwXiDW1M5TkCVv9nSf3nGZjl4sXsKPhZnUScW 4NiA== X-Gm-Message-State: AKS2vOzBzQ4+yjqllHLxgGE0vsdA7M66It2jFfvLScxFGF//1pE2u4iQ dD4gK2meyGf4hvdW5ca2XOrdnKwWwKLf X-Received: by 10.36.135.204 with SMTP id f195mr5814154ite.91.1498082356131; Wed, 21 Jun 2017 14:59:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Wed, 21 Jun 2017 14:58:55 -0700 (PDT) In-Reply-To: <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> From: Marius Scurtescu Date: Wed, 21 Jun 2017 14:58:55 -0700 Message-ID: To: "Richard Backman, Annabelle" Cc: "Phil Hunt (IDM)" , John Bradley , Henk Birkholz , Justin Richer , Yaron Sheffer , Michael Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c11bde2aefd7805527f7ada" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:59:22 -0000 --94eb2c11bde2aefd7805527f7ada Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Example for multiple events within same profile: IdP account is disabled (because of hijacking), this can lead to two events: 1. "account-disabled" 2. "sessions-revoked" Marius On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle < richanna@amazon.com> wrote: > The spec says that the events claim SHOULD NOT be used to express multipl= e > logical events. If it=E2=80=99s also not used to express events from diff= erent > profiles that correspond to the same logical event (e.g. an OIDC > backchannel logout event alongside a hypothetical RISC logout event), the= n > I=E2=80=99m not sure what use case that leaves for multiple events in one= SET. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of "Phil Hunt > (IDM)" > *Date: *Wednesday, June 21, 2017 at 2:12 PM > *To: *John Bradley > *Cc: *"Richard Backman, Annabelle" , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>, Justin Richer , Marius > Scurtescu , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Separate or combined may be evolving. Mike wants to keep the current > backchannel logout very narrowly scoped. He suggested risc define its own > duplicate definitions and meanings. > > > > That leads me to believe we will have multi-type events in practice. > > > > Session cancellation can occur for many reasons. One of the > differentiators we had tried to make was an assumption that user initiate= d > events would be part of connect. Risk would cover variations that drive o= ff > of risk calculations like password reset. > > > > There are also signout events at rp's to let the OP know. These are not > commands but notification that a resource session is cancelled. IOW singl= e > sign out not expected. > > > Phil > > > On Jun 21, 2017, at 1:58 PM, John Bradley wrote: > > I thought we decided that we are only allowing set messages form the same > family that agree on top level claims. > > > > Otherwise there can be no top level claims and we are really defining a > alternative format to JWT in some ways. > > > > John B. > > > > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > I agree with John that the JWT type confusion problem and the SET sub > problem can and should be discussed separately. The secevents WG is > probably not the right setting to discuss the former. > > > > My concern with the sub claim is that two profiles may dictate conflictin= g > semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B say= s it=E2=80=99s an > email address). If these profiles don=E2=80=99t provide an alternate way = to declare > subject of their events, then they cannot be present within the same toke= n. > This incompatibility trap seems like something that could be easily misse= d > by groups profiling SET. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *John Bradley > *Date: *Wednesday, June 21, 2017 at 1:39 PM > *To: *Yaron Sheffer > *Cc: *Justin Richer , Marius Scurtescu < > mscurtescu@google.com>, Annabelle Richard , Phil > Hunt , Michael Jones , > ID Events Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > In the envelope typ is a media/mime type. Registering application/idt+jw= t > if we register jwt as a structured name sufix. > > > > Using the cty is also possible. I need to think about what is better bu= t > we can agree on a convention. > > > > Not everything is going to be a set token like not every JWS is a JWT. > > > > If we are going to define processing rules to stop collisions and > confusion around JWT for different purposes, we should just start using t= he > typ parameter based on the existing spec. > > > > In general content sniffing if there is more than one option eventually > gets you into trouble. > > > > I am not convinced that forcing there to be no sub at the top level is a > good idea. > > > > It is not the way we should differentiate between SET and id_tokens. > > > > If sub is not allowed at the top level people will do non SET JWT for > things where the subject is scoped to the iss of the token. > > > > I think defining sub to be part of the event for cases where the sub is > scoped differently from the issuer of the token is fine, but should not b= e > required for all event types. > > > > I think we should solve the confusion issue separately from the sub issue= . > > > > Sorry I am at CIS so trying to catch up on lists. > > > > John B. > > > > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote: > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c11bde2aefd7805527f7ada Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Example for multiple events within same profile: IdP accou= nt is disabled (because of hijacking), this can lead to two events:
1. = "account-disabled"
2. "sessions-revoked"

Marius

On Wed, Jun 21, 2017 at 2:54 PM, Richard Bac= kman, Annabelle <richanna@amazon.com> wrote:

The spec says that the events claim SHOULD NOT be u= sed to express multiple logical events. If it=E2=80=99s also not used to ex= press events from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a = hypothetical RISC logout event), then I=E2=80=99m not sure what use case th= at leaves for multiple events in one SET.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM= )" <phil.= hunt@oracle.com>
Date: Wednesday, June 21, 2017 at 2:12 PM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkh= olz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Mari= us Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jo= nes <Mi= chael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Separate or combined may be evolving. Mike wants to = keep the current backchannel logout very narrowly scoped. He suggested risc= define its own duplicate definitions and meanings.=C2=A0

=C2=A0

That leads me to believe we will have multi-type eve= nts in practice.

=C2=A0

Session cancellation can occur for many reasons. One= of the differentiators we had tried to make was an assumption that user in= itiated events would be part of connect. Risk would cover variations that d= rive off of risk calculations like password reset.=C2=A0

=C2=A0

There are also signout events at rp's to let the= OP know. These are not commands but notification that a resource session i= s cancelled. IOW single sign out not expected.=C2=A0


Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing set m= essages form the same family that agree on top level claims.

=C2=A0

Otherwise there can be no top level claims and we ar= e really defining a alternative format to JWT in some ways.

=C2=A0

John B.

=C2=A0

On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabe= lle <richanna@a= mazon.com> wrote:

=C2=A0

I agree with John that t= he JWT type confusion problem and the SET sub problem can and should be dis= cussed separately. The secevents WG is probably not the right setting to discuss the former.

=C2=A0<= /u>

My concern with the sub = claim is that two profiles may dictate conflicting semantics (e.g. Profile = A says it=E2=80=99s a phone number, Profile B says it=E2=80=99s an email address). If these profiles don=E2=80=99t provide an alternate wa= y to declare subject of their events, then they cannot be present within th= e same token. This incompatibility trap seems like something that could be = easily missed by groups profiling SET.

=C2=A0<= /u>

--=C2=A0

Annabelle Richard Backman=

Identity Services<= u>

=C2=A0<= /u>

=C2=A0<= /u>

From:=C2=A0John Bradley <ve7jtb@ve7jtb.com>
Date:=C2=A0<= /span>Wednesday, June 21, 2017 at 1:39 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle = Richard <richan= na@amazon.com>, Phil Hunt <ph= il.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID= Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=C2= =A0Re: [Id-event] solution for Id/Access Token confusion and dis= tinct SET issuer

=C2=A0

In the envelope typ is a = media/mime type.=C2=A0 Registering application/idt+jwt if we register jwt a= s a structured name sufix. =C2=A0

=C2=A0

Using the cty is also pos= sible. =C2=A0 I need to think about what is better but we can agree on a co= nvention.

=C2=A0

Not everything is going t= o be a set token like not every JWS is a JWT.

=C2=A0

If we are going to define= processing rules to stop collisions and confusion around JWT for different= purposes, we should just start using the typ parameter based on the existi= ng spec.

=C2=A0

In general content sniffi= ng if there is more than one option eventually gets you into trouble.

=C2=A0

I am not convinced that f= orcing there to be no sub at the top level is a good idea. =C2=A0=

=C2=A0

It is not the way we shou= ld differentiate between SET and id_tokens.

=C2=A0

If sub is not allowed at = the top level people will do non SET JWT for things where the subject is sc= oped to the iss of the token.

=C2=A0

I think defining sub to b= e part of the event for cases where the sub is scoped differently from the = issuer of the token is fine, but should not be required for all event types= .

=C2=A0

I think we should solve t= he confusion issue separately from the sub issue.

=C2=A0

Sorry I am at CIS so tryi= ng to catch up on lists.

=C2=A0

John B.

=C2=A0

On Jun 17, 2017, at 3:45 = PM, Yaron Sheffer <yaronf.ietf@gmail.com> wro= te:

=C2=A0

So to summarize what I= 9;m seeing on this thread:

Everybody agrees with Mar= ius's short-term solution, specific rules for "sub" and "= ;iss" that can be defined in the SET spec.

Almost everybody agrees o= n a long-term "usage" claim ("type" is taken) that shou= ld be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add = a "usage" claim, we need to also use it in the SET document befor= e it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron<= u>

=C2=A0

On 15/06/17 22:08, Justin= Richer wrote:

+1 to this as well.=C2=A0<= u>

=C2=A0

=C2=A0=E2=80=94 Justin=

=C2=A0

On Jun 15, 2017, at 1:09 = PM, Marius Scurtescu <mscurtescu@google.com> = wrote:

=C2=A0

+1 to what Annabelle said= .=C2=A0<= u>

=C2=A0

Also, Mike you are missin= g the other requirement, for RPs to send events to an IdP. The iss+sub pair= at the top level is broken in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5= :33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com>= ; wrote:

+1

=C2=A0

Phil

<= /u>=C2=A0

On Jun 14, 2017, at 5:2= 5 PM, Richard Backman, Annabelle <richanna@amazon.com<= /a>> wrote:

Mike,

=C2=A0<= /u>

Your explanation for why= this is a non-problem is dependent upon side effects of elements of OpenID= Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The caller of the Token Endpoint is the only party that can be certain that a = nonce-less ID Token is really an ID Token. Any party that the caller passes= the ID Token off to has no way to verify its provenance.<= /u>

2.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Any future ID Token distribution method needs to solve this problem again.

3.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0No other profile of JWT can ever use the "nonce=E2=80=9D claim.

4.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0This is only a solution for ID Tokens. Every other JWT profile that cares about= disambiguation has to invent its own solution to the problem.

=C2=A0<= /u>

We know from experience = that naming collisions and replay attacks are both things that happen. What= =E2=80=99s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actu= ally makes it easier to use common libraries for JWT parsing. A =E2=80=9Cus= age-aware=E2=80=9D JWT library could handle disambiguation for any JWT prof= ile, whereas with the status quo each profile would require unique logic.

=C2=A0<= /u>

--=C2=A0

Annabelle Richard Backman=

Identity Services<= u>

=C2=A0<= /u>

=C2=A0<= /u>

From:=C2=A0Id-event <id-event-b= ounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com= >
Date:=C2=A0<= /span>Wednesday, June 14, 2017 at 1:16 PM
To:=C2=A0Marius Scurtescu <mscurtescu@google.com&= gt;
Cc:=C2=A0"Richard Backman, Annabelle" <richanna@amaz= on.com>, ID Events Mailing List <id-event@ietf.or= g>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=C2= =A0Re: [Id-event] solution for Id/Access Token confusion and dis= tinct SET issuer

=C2=A0

You=E2=80=99ve heard of =E2= =80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d characterize the p= roposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80= =93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0=

Mandatory solutions are bei= ng proposed in this thread to problems that there=E2=80=99s no evidence tha= t we actually even have.=C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see=C2= =A0https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.=C2=A0 If people have data showing that this is possible with specific kinds of A= ccess Tokens or other real JWT deployments, please provide specifics, so th= at we can use that data to inform appropriate engineering choices on our pa= rt.

=C2=A0=

The proposed =E2=80=9Csolut= ions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80=9D in the = normal way, or requiring a type claim, would make previously simple things = unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0=

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

=C2=A0

From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Beh= alf Of=C2=A0Richard Backman, Annabelle
Sent:=C2= =A0Tuesday, June 13, 2017 5:33 PM
To:=C2= =A0Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofe= r.de>
Cc:=C2= =A0ID Events Mailing List <id-event@ietf.org&= gt;
Subject:= =C2=A0Re: [Id-event] solution for Id/Access Token confusion and dist= inct SET issuer

=C2=A0

Echoing Marius=E2=80=99s= question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0<= /u>

To your first question, = I think a better analogy would be the X.509 Key Usage extension: a multi-va= lued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to = accept a JWT being presented to it in some context.

=C2=A0<= /u>

--=C2=A0

Annabelle Richard Backman=

Identity Services<= u>

=C2=A0<= /u>

=C2=A0<= /u>

From:=C2=A0Id-event <id-event-b= ounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date:=C2=A0<= /span>Tuesday, June 13, 2017 at 11:05 AM
To:=C2=A0Henk Birkholz <henk.birkholz@sit.fraunhof= er.de>
Cc:=C2=A0ID Events Mailing List <id-event@ietf.org>= ;
Subject:=C2= =A0Re: [Id-event] solution for Id/Access Token confusion and dis= tinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2= :11 AM, Henk Birkholz <henk.birkholz@sit.fraunhof= er.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience= ) specifies the target client, but not the intended usage (access token to = authorize resource access or SET to communicate a security event?)

=C2=A0

"scope" is not = used by SET.

=C2=A0

I don't know what do = you mean by "intend" (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this t= ogether!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--=C2=A0=

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org&= gt; on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com&g= t;
*Cc: *Adam Dawes <adawes@google.com>, "matak= e, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)&= quot; <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtes= cu@google.com<mailto:mscurtescu@google.com<= /span>>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <di= ck.hardt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>>= ; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0http://self-issued.info/?p=3D1690=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank">adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phi= l.hunt@oracle.com<mailto:phil.hunt@oracle.co= m>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank">mscurtescu@google.com

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:mscur= tescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&g= t;=C2=A0= Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.o= rg>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH= 0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mx= PQFJLhxWI&e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf= .org= =C2=A0<mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://ww= w.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google= .com> |= +1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410= >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0&= lt;mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--=C2=A0=

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>

=C2=A0

=C2=A0

_________________________= ______________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/i= d-event

=C2=A0





______________________________________=
_________
Id-event mailing list
Id-event@ietf.org
https://www.=
ietf.org/mailman/listinfo/id-event

=C2=A0

_________________________= ______________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--94eb2c11bde2aefd7805527f7ada-- From nobody Wed Jun 21 15:03:50 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E643128B37 for ; Wed, 21 Jun 2017 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWTaCvxY_g87 for ; Wed, 21 Jun 2017 15:03:42 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0134.outbound.protection.outlook.com [104.47.41.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5431C127369 for ; Wed, 21 Jun 2017 15:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3nLYmUQ0Cp1ffiU3HLSfF9K7A97yQrQCdWHJiv4Vprg=; b=WiOaxiBqKGJZnqYPXbVxgiygDvBtoEUMfCBfq/oNsC3XEIdc/eQIrNtrZIdgGzWu6ffiQy7roo3sCOXkMcBW64j9fer2qKy8JkA5a5juFBcEVEVUr6Qogo4iP+Sit7RgTtmvkqO/R/QPZuDsfEIPg/Qy189BgoGo1j1wvcdVoYU= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0134.namprd21.prod.outlook.com (10.173.189.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Wed, 21 Jun 2017 22:03:39 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.000; Wed, 21 Jun 2017 22:03:39 +0000 From: Mike Jones To: Marius Scurtescu CC: "M.Lizar@OCG" , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , "ID Events Mailing List" , Phil Hunt Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAAAQ5CAAwZmgIAAKJzwgAAI8wCAAvAHAIAAAcwAgAAQ2kCAABgSAIAACALA Date: Wed, 21 Jun 2017 22:03:38 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-21T17:03:35.0696392-05:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [208.59.64.25] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0134; 7:mUwDu+Suyn94D+IUGT3/Ngy0GtesyNhuF1RWC5CtA7+p+JxIof3mxxRQW0xV0bGQc94ekkZSWtUXEbCj223ztoxWqQRzJwNWxkx+DiilwF93bjulfjVOv1lhBmkumYIR7tYkpbPnrCLFRMJJjNhCl8bQJ+NJqrly5tZ2mN0FjK5G5CBhiXRkWkzXTqN5utXE2hbYOWuV+aMfGn4FQnVP+NkAUhfegweRHBlNdxJGCahpFTJag3rEOmhot3soBwIVxd4uxasF/Nx/L9K9XOUVNkNTovbLL2JxXDH3eWCo77pnxe6VQqL265WduIjd//ZhsdIGMiglW7N9XkTuB7aiFXuq31wXAKVusPhFaHU4eLj+WStYcmYaX7bB8xu/NZSHlUolR25klVFTQINYVbij5baVdS0mAmXWnWRQqnyn1pKHAM3sHunqCoekn75Tjv8OL1+TId6xrUZ3spjFRNBbs1phTwhiK6JiHn7gY8xqHFtjf9oqMha4I+W4vN6RbELExhp3hAoVmVFUP6uUdlUlsb2unBW8HfIpSvX502ak3vPSMu9VVEN60Eza5VPpdQQlay8v3QUA0K7hJ9JGeVbYm7fZ9eP4iJjr3NR1u+bqrikjgn/G2nevmuwe6ahQuPpC/sdrZYMxIMexgjc+VlVfkeM3cRkVhT4I/Dp1VQZW67P1GceGmL8H18g4UHViNfIrfquCajrgKQEDQibwPj6dX7JT592oArLimY34PS8QK+x+NL2Ey0OxDJGYhpTT50ZAtsATjLsUvxX0g7dbl13GotgatEJAFYrtjJIaSM7J6JeZ6nBApELoKcjoFQM/T8q3 x-ms-office365-filtering-correlation-id: 02c88aaa-97fc-46bc-4ad9-08d4b8f15f41 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:CY4PR21MB0134; x-ms-traffictypediagnostic: CY4PR21MB0134: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524)(211936372134217)(21748063052155)(21532816269658)(146099531331640)(47284530071512)(10436049006162)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0134; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0134; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39410400002)(39400400002)(39860400002)(39850400002)(209900001)(24454002)(377454003)(51914003)(377424004)(6116002)(102836003)(7906003)(7696004)(5660300001)(7736002)(790700001)(4326008)(99286003)(6506006)(6436002)(6246003)(39060400002)(55016002)(606005)(10290500003)(8936002)(38730400002)(110136004)(53376002)(10090500001)(5005710100001)(72206003)(14454004)(8990500004)(53936002)(3846002)(478600001)(74316002)(66066001)(81166006)(25786009)(966005)(86612001)(8676002)(2950100002)(6916009)(76176999)(54356999)(3280700002)(2900100001)(3660700001)(33656002)(50986999)(86362001)(575784001)(19609705001)(122556002)(77096006)(93886004)(54906002)(9686003)(6306002)(236005)(561944003)(189998001)(16200700003)(53946003)(229853002)(2906002)(54896002)(53546010)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0134; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05049568082B6C260AFDE06AF5DA0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 22:03:38.9324 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0134 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:03:48 -0000 --_000_CY4PR21MB05049568082B6C260AFDE06AF5DA0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaXVzLCB5b3Ugd3JvdGUg4oCcQlRXLCB5b3UgbmV2ZXIgb2ZmZXJlZCBhIHNvbHV0aW9uIHRv IHRoZSBSUCBpc3N1ZWQgU0VUcyBwcm9ibGVtIE1Ja2UuIENhbiB5b3UgcGxlYXNlIGRvIHRoYXQ/ 4oCdICBJIHRob3VnaHQgd2UgYWxyZWFkeSBoYWQgYSB3ZWxsLXVuZGVyc3Rvb2Qgc29sdXRpb24g dG8gdGhhdCwgYnV0IEnigJlsbCByZXBlYXQgaXQgaGVyZS4gIEnigJlsbCBnaXZlIHRoZSBleGFt cGxlIGFzc3VtaW5nIHRoYXQgdGhlIGV2ZW50IGlzIGFib3V0IGFuIE9wZW5JRCBDb25uZWN0IGFj Y291bnQgdGhhdCBpcyBuYW1lZCBieSBhbiAo4oCcaXNz4oCdLCDigJxzdWLigJ0pIHBhaXIuDQoN CklmIHRoZSBSUCBpcyBpc3N1aW5nIHRoZSBTRVQsIGl0IGFscmVhZHkgbXVzdCBpZGVudGlmeSBp dHNlbGYgdXNpbmcgdGhlIHRvcC1sZXZlbCDigJxpc3PigJ0gY2xhaW0sIHBlciB0aGUgU0VUIHNw ZWMuICBUaGUgT3BlbklEIENvbm5lY3QgYWNjb3VudCB0aGF0IGlzIHRoZSBzdWJqZWN0IG9mIHRo ZSBldmVudCB3b3VsZCBjb250YWluIHRoZSAo4oCcaXNz4oCdLCDigJxzdWLigJ0pIHZhbHVlcyBp biB0aGUgZXZlbnQgcGF5bG9hZC4gIEluIGZhY3QsIEnigJltIGFzc3VtaW5nIHRoYXQgdGhhdCB3 b3VsZCBiZSB0aGUgY2FzZSBmb3IgYWxsIFJJU0MgZXZlbnRzIChhbmQgcG9zc2libHkgZm9yIHNv bWUgb3RoZXIgZXZlbnQgcHJvZmlsZXMgdG9vKS4gIEnigJltIGNvbXBsZXRlbHkgc3VwcG9ydGl2 ZSBvZiB0aGF0IGNob2ljZSBpZiBtYWRlIGJ5IGEgcHJvZmlsZS4NCg0KQnV0IHRoZXJlIHdpbGwg YWxzbyBiZSB1c2UgY2FzZXMg4oCTIHBvc3NpYmx5IG5vbi1pZGVudGl0eSB1c2UgY2FzZXMsIGlu IHdoaWNoIHRoZSB0aGluZyBiZWluZyBvcGVyYXRlZCBvbiBkb2VzbuKAmXQgaGF2ZSBhbnkgaXNz dWVyIHZhbHVlIG9yIGluIHdoaWNoIHRoZSBldmVudCBpc3N1ZXIgaXMgYWx3YXlzIHRoZSBzYW1l IGFzIHRoZSBpc3N1ZXIgZm9yIHRoZSB0aGluZyBiZWluZyBvcGVyYXRlZCBvbi4gIFRyeWluZyB0 byBpbXBvc2UgdGhlIGNob2ljZXMgbWFkZSBieSBvbmUgU0VUIHByb2ZpbGUgb250byBhbGwgb3Ro ZXJzLCB0aG91Z2gsIGFzc3VtZXMgd2Uga25vdyB3YXkgbW9yZSBhYm91dCB0aGVpciB1c2UgY2Fz ZXMgdGhhbiB3ZSBhY3R1YWxseSBkby4gIFdlIG5lZWQgdG8gbGVhdmUgdGhlaXIgY29udmVudGlv bnMgdXAgdG8gdGhlbSDigJMganVzdCBsaWtlIEpXVCBsZWZ0IGNsYWltcyBjb252ZW50aW9ucyB1 cCB0byBwcm9maWxlcy4gIFRoYXTigJlzIHdoeSBpdOKAmXMgZ2VuZXJhbC1wdXJwb3NlIGFuZCBi ZWluZyB3aWRlbHkgdXNlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWFyaXVzIFNjdXJ0ZXNjdSBbbWFp bHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMSwgMjAx NyA0OjIwIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0K Q2M6IE0uTGl6YXJAT0NHIDxtLmxpemFyQG9wZW5jb25zZW50Z3JvdXAuY29tPjsgUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb20+OyBIZW5rIEJpcmtob2x6IDxo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPjsgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PjsgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPjsgSUQgRXZlbnRz IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+OyBQaGlsIEh1bnQgPHBoaWwuaHVudEBv cmFjbGUuY29tPg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2Vz cyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KT24gV2VkLCBKdW4g MjEsIDIwMTcgYXQgMToxOSBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCk1hcml1cywg dGhlIHF1ZXN0aW9uIOKAnERvIHlvdSBoYXZlIGV4YW1wbGVzIG9mIHVzZSBjYXNlcyB0aGF0IGNh bm5vdCBoYW5kbGUgc3ViIGF0IHRoZSBldmVudCBsZXZlbD/igJ0gaXMgbm8gbW9yZSB1c2VmdWwg dGhhbiB0aGUgcXVlc3Rpb24g4oCcRG8geW91IGhhdmUgZXhhbXBsZXMgb2YgdXNlIGNhc2VzIHRo YXQgY2Fubm90IGhhbmRsZSDigJhzdWLigJkgc3BlbGxlZCBhcyB0aGUgTGF0aW4gd29yZCDigJhz dWJpZWN0dW3igJk/4oCdDQoNCkkgZGlzYWdyZWUuIElmIHN1YiBhdCB0aGUgZXZlbnQgbGV2ZWwg aXMgYW4gaXNzdWUgdGhlbiBsZXQncyBiZSBjb25jcmV0ZSBhYm91dCBpdC4NCg0KDQogIFllcywg YXBwbGljYXRpb25zIGNvdWxkIGFsd2F5cyB3b3JrIGFyb3VuZCB0aGUgaW5jb252ZW5pZW5jZXMg aW50cm9kdWNlZCBieSBhcmJpdHJhcnkgY2xhaW0gcmVuYW1pbmcgb3IgcmVwb3NpdGlvbmluZywN Cg0KVGhpcyBpcyBub3QgYW4gYXJiaXRyYXJ5IHJlcG9zaXRpb25pbmcsIHRoZSByZWFzb25zIGEg dmVyeSBjbGVhci4NCg0KDQpidXQgdGhleSBzaG91bGRu4oCZdCBoYXZlIHRvLiAgSXQganVzdCBh ZGRzIGNvbXBsZXhpdHkgYW5kIHdpbGwgaGluZGVyIGFkb3B0aW9uLg0KDQpNaW5vciBjb21wbGV4 aXR5IGFkZGVkLCBpZiBhdCBhbGwuIFRoZSBvbmx5IGRvd25zaWRlIGlzIHRoZSBzbGlnaHRseSBs YXJnZXIgc2l6ZSBvZiBTRVRzLg0KDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgeW91ciBtb3RpdmF0 aW9uIGZvciBhbHdheXMgaGF2aW5nIOKAnHN1YuKAnSBpbiB0aGUgZXZlbnQgcGF5bG9hZCwgcmF0 aGVyIHRoYW4gYSBub3JtYWwgY2xhaW0sIGlzIHRoYXQgdGhhdOKAmXMgaG93IHlvdSB0aGluayBS SVNDIGV2ZW50cyB3aWxsIGJlIHN0cnVjdHVyZWQsIGFuZCB0aGF0IHlvdSB3YW50ICphbGwqIGV2 ZW50cyB0byBhbHNvIHVzZSB0aGUgUklTQyBldmVudCBzdHJ1Y3R1cmluZy4NCg0KVGhpcyBoYXMg YWJzb2x1dGVseSBub3RoaW5nIHRvIGRvIHdpdGggUklTQyBpbiBwYXJ0aWN1bGFyLiBCb3RoIHRo ZSBjb25mdXNpb24gcHJvYmxlbSBhbmQgdGhlIFJQIGlzc3VlZCBTRVRzIGFyZSBnZW5lcmljIFNF VCBwcm9ibGVtcyB0aGF0IG5lZWQgdG8gYmUgc29sdmVkLg0KDQpCVFcsIHlvdSBuZXZlciBvZmZl cmVkIGEgc29sdXRpb24gdG8gdGhlIFJQIGlzc3VlZCBTRVRzIHByb2JsZW0gTUlrZS4gQ2FuIHlv dSBwbGVhc2UgZG8gdGhhdD8NCg0KDQogIFRvIG15IHdheSBvZiB0aGlua2luZywgaWYgeW91IHJl YWxseSBiZWxpZXZlIHRoYXQgeW91IHNob3VsZCBiZSBhc2tpbmcgdGhlIFNFVCBzcGVjIHRvIGJl IHdpdGhkcmF3biBmcm9tIHRoZSBJRVRGIGFuZCBvbmx5IGRlZmluZSBSSVNDIGV2ZW50cyBpbiB0 aGUgUklTQyB3b3JraW5nIGdyb3VwLiAgQnV0IGluIGZhY3QsIHJlcXVpcmluZyBhbGwgZXZlbnRz IHRvIGZvbGxvdyB0aGUgUklTQyBjb252ZW50aW9ucyBtYWtlcyBubyBtb3JlIHNlbnNlIHRoYW4g cmVxdWlyaW5nIGFsbCBKV1RzIHRvIGJlIElEIFRva2Vucy4gIFRoYXQgd291bGQgaGF2ZSBtYWRl IEpXVHMgdXNlbGVzcyBmb3IgbWFueSB1c2UgY2FzZXMuICBQcm9wb3NpbmcgdG8gbGltaXQgY2xh aW1zIHVzYWdlIGluIFNFVHMgd291bGQgbGlrZXdpc2UgbWFrZSB0aGVtIGluYXBwbGljYWJsZSBm b3IgbWFueSBub24tUklTQyB1c2UgY2FzZXMuDQoNCldlIGhhdmUgYSBwb3RlbnRpYWwgc3VjY2Vz cyBvbiBvdXIgaGFuZHMuICBMZXTigJlzIG5vdCBzY3JldyBpdCB1cCBieSBtYWtpbmcgaXQgdW5u ZWNlc3NhcmlseSBjb21wbGljYXRlZC4NCg0KU3VyZSwgbGV0J3Mgc29sdmUgYWxsIG9wZW4gaXNz dWVzIGZpcnN0Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzpt c2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT5dDQpTZW50 OiBXZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcgMTo1MyBQTQ0KVG86IE0uTGl6YXJAT0NHPG1haWx0 bzpNLkxpemFyQE9DRz4gPG0ubGl6YXJAb3BlbmNvbnNlbnRncm91cC5jb208bWFpbHRvOm0ubGl6 YXJAb3BlbmNvbnNlbnRncm91cC5jb20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IFJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9m ZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+PjsgSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjsgWWFyb24gU2hl ZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+ PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnPj47IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24g Zm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0K T24gV2VkLCBKdW4gMjEsIDIwMTcgYXQgMTE6NDYgQU0sIE0uTGl6YXJAT0NHPG1haWx0bzpNLkxp emFyQE9DRz4gPG0ubGl6YXJAb3BlbmNvbnNlbnRncm91cC5jb208bWFpbHRvOm0ubGl6YXJAb3Bl bmNvbnNlbnRncm91cC5jb20+PiB3cm90ZToNCkZXSVcgLSBJIGFncmVlIHdpdGggTWlrZSB0aGF0 IHB1dHRpbmcgcmVzdHJpY3Rpb25zIG9uIHRoZSAic3ViIiBjbGFpbSB1c2FnZSB3b3VsZCB1bm5l Y2Vzc2FyaWx5IGNvbXBsaWNhdGUgU0VUcyBmb3Igc29tZSB1c2UgY2FzZXMuDQoNCnN1YiBpcyBk ZWZpbmVkIGFzIG9wdGlvbmFsIGluIEpXVCwgc28gdGVjaG5pY2FsbHkgd2UgYXJlIG5vdCBhZGRp bmcgYW55IHJlc3RyaWN0aW9ucy4gRG8geW91IGhhdmUgZXhhbXBsZXMgb2YgdXNlIGNhc2VzIHRo YXQgY2Fubm90IGhhbmRsZSBzdWIgYXQgdGhlIGV2ZW50IGxldmVsPw0KDQoNCg0KSXRzIGEgbG90 IGVhc2llciB0byBhZGQgdG8gYSBzcGVjIGFuZCB2ZXJ5IGRpZmZpY3VsdCAoaWYgbm90IGltcG9z c2libGUpIHRvIHJldHJhY3QuDQoNCkkgYWdyZWUuIEkgZG9uJ3QgdGhpbmsgYW55dGhpbmcgaXMg cmV0cmFjdGVkLg0KDQpBZ2Fpbiwgc2VlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc1MTkjc2VjdGlvbi00LjEuMg0KDQpMYXN0IHNlbnRlbmNlIG9mIDQuMS4yIHN0YXRlcyAiVXNl IG9mIHRoaXMgY2xhaW0gaXMgT1BUSU9OQUwuIg0KDQoNCkluIHRoaXMgcmVnYXJkLCBrZWVwaW5n IGl0IHNpbXBsZSBpcyBjcml0aWNhbCBmb3IgYnJvYWQgYWRvcHRpb24uDQoNCk1hcmsNCg0KT24g MTkgSnVuIDIwMTcsIGF0IDE2OjU1LCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2ds ZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpNaWtlLCBhcmUg eW91IHN1Z2dlc3Rpbmcgd2UgZGVmaW5lIFNFVHMgaW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgd2ls bCBub3Qgd29yayBmb3IgUklTQz8gQSB0b3AgbGV2ZWwgaXNzK3N1YiBpcyBjbGVhcmx5IG5vdCB3 b3JraW5nIGZvciBSSVNDLCBhbmQgbWF5IG5vdCB3b3JrIGZvciBsb2dvdXQgZWl0aGVyIGlmIHlv dSBhbGxvdyBsb2dvdXQgdG8gYmUgaW5pdGlhdGVkIGZyb20gYW4gUlAuDQoNCk1hcml1cw0KDQpP biBNb24sIEp1biAxOSwgMjAxNyBhdCAyOjI3IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KTWFyaXVzLCB0aGVyZeKAmXMgbm90aGluZyBzdG9wcGluZyB5b3UgKG9yIHRoZSBSSVNDIHdv cmtpbmcgZ3JvdXAgb3Igb3RoZXIgcHJvZmlsZXMpIGZyb20gZGVmaW5pbmcgZXZlbnRzIHRoYXQg Y2FuIGJlIHNlbnQgZnJvbSBSUHMgdG8gSWRQcyBub3csIHdpdGhvdXQgYW55IGNoYW5nZXMgdG8g dGhlIFNFVCBzcGVjLiAgU3BlY2lmeSB0aGUgY2xhaW1zIHlvdSB3YW50IHRvIHVzZSwgYW5kIHlv deKAmXJlIGdvbGRlbi4NCg0KQnV0IGl0IHdvdWxkIGJlIGNvdW50ZXJwcm9kdWN0aXZlIHRvIHJl cXVpcmUgYWxsIG90aGVyIFNFVHMgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIHlvdXIgc3Bl Y2lmaWMgcHJvZmlsZS4gIFRoZXJlIGFyZSBzaW1wbGVyIHVzZSBjYXNlcyB0aGF0IGNhbiB1c2Ug Y2xhaW1zIGluIHNpbXBsZXIgd2F5cy4gIFRyeWluZyB0byBtYWtlIHRoZSBzaW1wbGUgdXNlIGNh c2VzIGJlIGNvbXBsZXggd2lsbCBoYXZlIHRoZSBzaWRlIGVmZmVjdCBvZiBsaW1pdGluZyB0aGUg YWRvcHRpb24gb2YgdGhlIHNwZWMsIHdoaWNoIHdvdWxkbuKAmXQgYmUgZ29vZCBmb3IgYW55b25l Lg0KDQpJZiBzdWNjZXNzZnVsLCBTRVRzIHdpbGwgaGF2ZSBtYW55IGRpZmZlcmVudCBwcm9maWxl cy4gIFRoYXTigJlzIGEgc2lnbiBvZiBzdWNjZXNzIOKAkyBub3QgYSBzaWduIG9mIHdlYWtuZXNz Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+XQ0KU2VudDogTW9uZGF5LCBK dW5lIDE5LCAyMDE3IDExOjU4IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFlhcm9u IFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwu Y29tPj47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1h aWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+ PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnPj47IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24g Zm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0K DQpPbiBTYXQsIEp1biAxNywgMjAxNyBhdCAyOjA2IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KSeKAmW0gc29ycnkgdG8gYmUgc2xvdyByZXBseWluZyB0byBzb21lIG1lc3NhZ2VzIGlu IHRoaXMgdGhyZWFkLiAgSSBoYXZlIGEgbG90IG9mIG90aGVyIHRoaW5ncyBvbiBteSBwbGF0ZSwg YnV0IEkgd2lsbCB0YWtlIHRoZSB0aW1lIG5vdyB0byByZXBseSwgYmVjYXVzZSBJIHdob2xlaGVh cnRlZGx5IGRpc2FncmVlIHdpdGggc29tZSBvZiB0aGUgc3RhdGVtZW50cyBiZWxvdyBhbmQgYmVs aWV2ZSBpdCB3b3VsZCBiZSBzZXZlcmVseSBoYXJtZnVsIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGFu ZCBpdHMgYWRvcHRpb24gdG8gYWN0IHVwb24gdGhlbS4gIFNwZWNpZmljYWxseToNCg0KDQogICog ICBJIGRpc2FncmVlIHRoYXQgc3BlY2lmaWMgcnVsZXMgc2hvdWxkIGJlIG1hZGUgZm9yIHRoZSDi gJxzdWLigJ0gY2xhaW0uICBDbGFpbXMgdXNhZ2UgbmVlZHMgdG8gYmUgdXAgdG8gdGhlIGFwcGxp Y2F0aW9uLiAgSSBrbm93IHRoYXQgbWFueSBvdGhlcnMgYWdyZWUgd2l0aCBtZSwgYmVjYXVzZSB0 aGUgT3BlbklEIENvbm5lY3Qgd29ya2luZyBncm91cCBkZXNpZ25lZCB0aGUgbG9nb3V0IHRva2Vu IGluIGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJhY2tjaGFubmVsLTFf MC0wNC5odG1sI0xvZ291dFRva2VuICh3aGljaCBpcyBhbHNvIHVzZWQgYXMgYW4gZXhhbXBsZSBp biBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0w MSNzZWN0aW9uLTIpIHRvIHVzZSB0aGUg4oCcc3Vi4oCdIGNsYWltIGluIHRoZSBub3JtYWwgd2F5 LiAgUHJvaGliaXRpbmcgdGhpcyB1c2FnZSB3b3VsZCBiZSBhIGNvbXBsZXRlbHkgdW5uZWNlc3Nh cnkgYnJlYWtpbmcgY2hhbmdlIOKAkyBhcyBpdOKAmXMgaW1wb3NzaWJsZSB0byBjb25mdXNlIGEg bG9nb3V0IHRva2VuIHdpdGggYW4gSUQgVG9rZW4sIGZvciByZWFzb25zIGFscmVhZHkgY2l0ZXMg aW4gdGhpcyB0aHJlYWQuDQpTb2x2aW5nIHRoZSBjb25mdXNpb24gaXMgb25lIHByb2JsZW0uIFRo ZSBvdGhlciBwcm9ibGVtIEkga2VlcCBtZW50aW9uaW5nIGlzIFNFVHMgaXNzdWVkIGJ5IGFuIFJQ IHRvIGJlIHNlbnQgdG8gYW4gSWRQLiBIb3cgYXJlIHdlIHNvbHZpbmcgdGhhdCBwcm9ibGVtIE1p a2U/IEluIHRoaXMgY2FzZSB0aGUgdG9wIGxldmVsIGlzcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUg aXNzIG9mIHRoZSBzdWIsIGEgdG9wIGxldmVsIHN1YiBpcyBub3QgcG9zc2libGUuDQoNCkFuZCBJ IGRvbid0IHdhbnQgdG8gZG93bnBsYXkgdGhlIGNvbmZ1c2lvbiBwcm9ibGVtIGVpdGhlci4gSSB0 aGluayBpdCBpcyBhIHJlYWwgY29uY2VybiBhbmQgSSB0aGluayBhIHNvbGlkIHNvbHV0aW9uIGlz IGltcG9ydGFudC4NCg0KVGhlIE9wZW5JRCBXb3JraW5nIEdyb3VwIGRlc2lnbmVkIGxvZ291dCB0 b2tlbnMgd2l0aG91dCBzZWNldmVudCBpbiBtaW5kLiBJIGFncmVlIHdlIHNob3VsZCBub3QgcmVj a2xlc3NseSBicmVhayBjb21wYXRpYmlsaXR5LCBidXQgdG8gbWUgaXQgc2VlbXMgbmVjZXNzYXJ5 IGluIHRoaXMgY2FzZS4NCg0KDQogICoNCg0KDQogICogICAoSSBhZ3JlZSB3aXRoIHRoZSDigJxp c3PigJ0gcnVsZXMgYWxyZWFkeSBpbiBwbGFjZSBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zZWNldmVudC10b2tlbi0wMSNzZWN0aW9uLTIuMS4gIE5vIGZ1cnRoZXIg 4oCcaXNz4oCdIHJ1bGVzIGFyZSBuZWVkZWQuKQ0KDQpGdXJ0aGVyIGlzcyBydWllcyBhcmUgYWJz b2x1dGVseSBuZWVkZWQgZm9yIHRoZSBSUCB0byBJZFAgY2FzZSBkZXNjcmliZWQgYWJvdmUuDQoN Cg0KDQogICoNCg0KDQogICogICBJdOKAmXMgZmluZSBmb3IgdGhlIOKAnHR5cOKAnSBoZWFkZXIg cGFyYW1ldGVyIHRvIGJlIHVzZWQgZm9yIHNvbWUgcHJvZmlsZXMgdG8gZGlmZmVyZW50aWF0ZSBi ZXR3ZWVuIGtpbmRzIG9mIEpXVHMuICBJdHMgdXNlIHNob3VsZCBub3QgYmUgbWFuZGF0ZWQgaW4g dGhlIFNFVCBzcGVjLiAgSSB3b3VsZCBvcHBvc2UgZHVwbGljYXRpbmcgdGhlIOKAnHR5cOKAnSBm dW5jdGlvbmFsaXR5IGJ5IGRlZmluaW5nIGFub3RoZXIgY2xhaW0gd2l0aCBhIGR1cGxpY2F0aXZl IG1lYW5pbmcuDQpJZiB0eXAgY2FuIGJlIHVzZSBhbmQgbm8gb3RoZXIgY2xhaW0gaXMgbmVlZGVk LCB0aGVuIGxldCdzIHRhbGsgYWJvdXQgdGhhdC4gSSBkbyB0aGluayBTRVQgc2hvdWxkIG1hbmRh dGUgaXQuIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgbm90LiBDYW4geW91IHBsZWFzZSBwcm9wb3Nl IHdpdGggZXhhbXBsZXMgaG93IGNhbiB0eXAgYmUgdXNlZD8NCg0KDQoNCiAgKg0KDQoNCiAgKiAg IEnigJlsbCBhbHNvIHJlc3BvbmQgdG8gQW5uYWJlbGxl4oCZcyBhc3NlcnRpb24gdGhhdCDigJxO byBvdGhlciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2UgdGhlICJub25jZeKAnSBjbGFpbS7i gJ0gIFRoaXMgcmVmbGVjdHMgYSBtaXN1bmRlcnN0YW5kaW5nLiAgSXTigJlzIHRoZSAqdmFsdWUq IG9mIHRoZSBub25jZSB0aGF0IHNlbGYtc2VjdXJlcyB0aGUgSldUIOKAkyBub3QgdGhhdCBhbnkg 4oCcbm9uY2XigJ0gY2xhaW0gaXMgcHJlc2VudC4gIEFueSBhbmQgYWxsIEpXVHMgY2FuIHNpbXVs dGFuZW91c2x5IHVzZSDigJxub25jZeKAnSB3aXRob3V0IGFueSByaXNrIG9mIGNvbmZsaWN0LCBz aW5jZSB0aGUgbm9uY2UgdmFsdWUgaXMgYSBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUgcmFuZG9t IG51bWJlci4NCg0KRm9yIFNFVHMgSSBjYW5ub3Qgc2VlIGhvdyB0aGUgbm9uY2UgdmFsdWUgaXMg dXNlZnVsLiBUaGF0IHZhbHVlIGlzIG5vdCBwYXNzZWQgYmFjayBhbmQgaXQgY2Fubm90IGJlIHZl cmlmaWVkLiBPbmx5IHRoZSBwcmVzZW5jZSBvZiB0aGUgY2xhaW0gY291bGQgaGF2ZSBzb21lIHVz ZSwgaGludGluZyBhdCB0aGUgdXNhZ2Ugb2YgdGhlIEpXVCwgYSB2ZXJ5IHdlYWsgc29sdXRpb24g dG8gdGhlIGNvbmZ1c2lvbiBwcm9ibGVtLg0KDQoNCiAgKg0KDQpXaWxsIHNvbWUgb2YgeW91IGJl IGF0IHRoZSBDbG91ZCBJZGVudGl0eSBTdW1taXQgbmV4dCB3ZWVrPyAgSeKAmWQgYmUgZ2xhZCB0 byBoYXZlIGluLXBlcnNvbiBkaXNjdXNzaW9ucyBhYm91dCB0aGVzZSB0b3BpY3MgdGhlcmUuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNClAuUy4gIEZvb2QgZm9yIHRob3VnaHQ6ICBQcm9oaWJpdGluZyB0aGUgdXNlIG9m IOKAnHN1YuKAnSAob3IgYW55IG90aGVyIGNsYWltKSBvciBmb3JjaW5nIGl0IHRvIGJlIGxvY2F0 ZWQgaW4gYSBub24tc3RhbmRhcmQgbG9jYXRpb24gbWFrZXMgYWJvdXQgYXMgbXVjaCBzZW5zZSBh cyBhcmJpdHJhcmlseSBzYXlpbmcgdGhhdCwgZm9yIGEgcGFydGljdWxhciBwcm9maWxlLCB0aGUg TGF0aW4gd29yZCBmb3Igc3ViamVjdCDigJxzdWJpZWN0dW3igJ0gbXVzdCBiZSB1c2VkIGFzIHRo ZSBjbGFpbSBuYW1lIGluc3RlYWQgb2Yg4oCcc3Vi4oCdLiAgWWVzLCBpdCB3aWxsIGNvbXBsZXRl bHkgZGlmZmVyZW50aWF0ZSB0aGlzIHByb2ZpbGUgZnJvbSBvdGhlcnMgbm90IHNwZWxsaW5nIHRo ZSBjbGFpbSBuYW1lIHRoaXMgd2F5LCBidXQgaXQgd291bGQgY2VydGFpbmx5IGJlIGFuIGltcGVk aW1lbnQgdG8gdGhlIHVzZSBvZiBzdGFuZGFyZCBKV1QgbGlicmFyaWVzIGFuZCB0byBpbnRlcm9w ZXJhYmlsaXR5Lg0KDQpJZiB3ZSBkZWZpbmUgdGhhdCBzdWIgbXVzdCBiZSBhdCB0aGUgZXZlbnQg bGV2ZWwgdGhlbiBpdCBpcyBhdCBhIHN0YW5kYXJkIGxvY2F0aW9uLCBJIGRvbid0IHNlZSB3aGF0 IHRoZSBpc3N1ZSBpcy4gVGhlIGltcGVkaW1lbnQgeW91IG1lbnRpb24gaXMgdGhlIGFjdHVhbCBz b2x1dGlvbi4gSSBkb24ndCB0aGluayB0aGF0IGEgSldUIGxpYnJhcnkgdGhhdCB3YXMgd3JpdHRl biBmb3IgSWQgVG9rZW5zIHNob3VsZCBiZSB1c2VkIHRvIHBhcnNlIFNFVHMuIFRoZSBsaWJyYXJ5 IGhhcyB0byBiZSBTRVQgYXdhcmUsIGluIHdoaWNoIGNhc2UgdGhlIGV2ZW50IGxldmVsIGlzcytz dWIgaXMgbm90IGFuIGlzc3VlIGF0IGFsbC4NCg0KDQoNCg0KRnJvbTogWWFyb24gU2hlZmZlciBb bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t Pl0NClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDE3LCAyMDE3IDE6NDUgUE0NClRvOiBKdXN0aW4gUmlj aGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+OyBNYXJpdXMgU2N1 cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bT4+DQpDYzogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hQGFtYXpvbi5jb208 bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgSGVuayBC aXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+PjsgUGhpbCBIdW50IDxwaGlsLmh1 bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KDQpTdWJqZWN0OiBS ZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQg ZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQoNClNvIHRvIHN1bW1hcml6ZSB3aGF0IEknbSBzZWVpbmcg b24gdGhpcyB0aHJlYWQ6DQoNCkV2ZXJ5Ym9keSBhZ3JlZXMgd2l0aCBNYXJpdXMncyBzaG9ydC10 ZXJtIHNvbHV0aW9uLCBzcGVjaWZpYyBydWxlcyBmb3IgInN1YiIgYW5kICJpc3MiIHRoYXQgY2Fu IGJlIGRlZmluZWQgaW4gdGhlIFNFVCBzcGVjLg0KDQpBbG1vc3QgZXZlcnlib2R5IGFncmVlcyBv biBhIGxvbmctdGVybSAidXNhZ2UiIGNsYWltICgidHlwZSIgaXMgdGFrZW4pIHRoYXQgc2hvdWxk IGJlIGRlZmluZWQgZWxzZXdoZXJlLCBlLmcuIGluIHRoZSBKV1QgQkNQLg0KDQpEaWQgSSBtaXNz IGFueXRoaW5nPw0KDQpCeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAidXNhZ2UiIGNsYWltLCB3 ZSBuZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1lbnQgYmVmb3JlIGl0IGlzIHB1 Ymxpc2hlZC4NCg0KVGhhbmtzLA0KDQogICAgWWFyb24NCg0KT24gMTUvMDYvMTcgMjI6MDgsIEp1 c3RpbiBSaWNoZXIgd3JvdGU6DQorMSB0byB0aGlzIGFzIHdlbGwuDQoNCiDigJQgSnVzdGluDQoN Ck9uIEp1biAxNSwgMjAxNywgYXQgMTowOSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNj dUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiB3cm90ZToNCg0KKzEg dG8gd2hhdCBBbm5hYmVsbGUgc2FpZC4NCg0KQWxzbywgTWlrZSB5b3UgYXJlIG1pc3NpbmcgdGhl IG90aGVyIHJlcXVpcmVtZW50LCBmb3IgUlBzIHRvIHNlbmQgZXZlbnRzIHRvIGFuIElkUC4gVGhl IGlzcytzdWIgcGFpciBhdCB0aGUgdG9wIGxldmVsIGlzIGJyb2tlbiBpbiB0aGlzIGNhc2UuDQoN Ck1hcml1cw0KDQpPbiBXZWQsIEp1biAxNCwgMjAxNyBhdCA1OjMzIFBNLCBQaGlsIEh1bnQgKElE TSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdy b3RlOg0KKzENCg0KUGhpbA0KDQpPbiBKdW4gMTQsIDIwMTcsIGF0IDU6MjUgUE0sIFJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBh bWF6b24uY29tPj4gd3JvdGU6DQpNaWtlLA0KDQpZb3VyIGV4cGxhbmF0aW9uIGZvciB3aHkgdGhp cyBpcyBhIG5vbi1wcm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNpZGUgZWZmZWN0cyBvZiBlbGVt ZW50cyBvZiBPcGVuSUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRo aXMgaXNzdWUuIEFzIGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsIGlzc3VlcyB3aXRoIGl0Og0KDQox LiAgICAgICBUaGUgY2FsbGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0 eSB0aGF0IGNhbiBiZSBjZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxs eSBhbiBJRCBUb2tlbi4gQW55IHBhcnR5IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRv a2VuIG9mZiB0byBoYXMgbm8gd2F5IHRvIHZlcmlmeSBpdHMgcHJvdmVuYW5jZS4NCg0KMi4gICAg ICAgQW55IGZ1dHVyZSBJRCBUb2tlbiBkaXN0cmlidXRpb24gbWV0aG9kIG5lZWRzIHRvIHNvbHZl IHRoaXMgcHJvYmxlbSBhZ2Fpbi4NCg0KMy4gICAgICBObyBvdGhlciBwcm9maWxlIG9mIEpXVCBj YW4gZXZlciB1c2UgdGhlICJub25jZeKAnSBjbGFpbS4NCg0KNC4gICAgICBUaGlzIGlzIG9ubHkg YSBzb2x1dGlvbiBmb3IgSUQgVG9rZW5zLiBFdmVyeSBvdGhlciBKV1QgcHJvZmlsZSB0aGF0IGNh cmVzIGFib3V0IGRpc2FtYmlndWF0aW9uIGhhcyB0byBpbnZlbnQgaXRzIG93biBzb2x1dGlvbiB0 byB0aGUgcHJvYmxlbS4NCg0KV2Uga25vdyBmcm9tIGV4cGVyaWVuY2UgdGhhdCBuYW1pbmcgY29s bGlzaW9ucyBhbmQgcmVwbGF5IGF0dGFja3MgYXJlIGJvdGggdGhpbmdzIHRoYXQgaGFwcGVuLiBX aGF04oCZcyBiZWluZyBwcm9wb3NlZCBpcyBhIHNpbXBsZSwgZGVmZW5zaXZlIG1lYXN1cmUgYWdh aW5zdCB0aGVzZSByaXNrcy4gWW91IGJyb3VnaHQgdXAgSldUIGxpYnJhcmllczogYSBnZW5lcmFs IHNvbHV0aW9uIGFjdHVhbGx5IG1ha2VzIGl0IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJhcmll cyBmb3IgSldUIHBhcnNpbmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQg aGFuZGxlIGRpc2FtYmlndWF0aW9uIGZvciBhbnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aCB0 aGUgc3RhdHVzIHF1byBlYWNoIHByb2ZpbGUgd291bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMuDQoN Ci0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZy b206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkRhdGU6 IFdlZG5lc2RheSwgSnVuZSAxNCwgMjAxNyBhdCAxOjE2IFBNDQpUbzogTWFyaXVzIFNjdXJ0ZXNj dSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pg0K Q2M6ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFp bHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4sIEhlbmsgQmlya2hvbHogPGhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZy YXVuaG9mZXIuZGU+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KWW914oCZdmUg aGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4gIEnigJlkIGNoYXJhY3Rlcml6 ZSB0aGUgcHJvcG9zYWxzIGluIHRoaXMgdGhyZWFkIGFzIOKAnHByZW1hdHVyZSBwZXNzaW1hdGlv buKAnSDigJMgbWFraW5nIHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hvdWxkIGJlIHNpbXBsZSBjb21w bGV4LCB3aXRob3V0IGRhdGEgc2hvd2luZyB0aGVyZeKAmXMgYW55IG5lZWQgdG8gZG8gc28uDQoN Ck1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGluIHRoaXMgdGhyZWFkIHRv IHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0dWFsbHkgZXZl biBoYXZlLiAgSXTigJlzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hlZCB0aGF0IGl04oCZcyBpbXBv c3NpYmxlIGZvciBhIFNFVCB0byBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4g4oCTIHNlZSBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNn MDA0MjguaHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRldmVudF9jdXJyZW50 X21zZzAwNDI4Lmh0bWwmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1lS0xUUVBt WXJWM1RoZkRibjkwU0NzNTVVUk9UUGluX2xnYzZSZHI1WG93JmU9Pi4gIElmIHBlb3BsZSBoYXZl IGRhdGEgc2hvd2luZyB0aGF0IHRoaXMgaXMgcG9zc2libGUgd2l0aCBzcGVjaWZpYyBraW5kcyBv ZiBBY2Nlc3MgVG9rZW5zIG9yIG90aGVyIHJlYWwgSldUIGRlcGxveW1lbnRzLCBwbGVhc2UgcHJv dmlkZSBzcGVjaWZpY3MsIHNvIHRoYXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEgdG8gaW5mb3JtIGFw cHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNob2ljZXMgb24gb3VyIHBhcnQuDQoNClRoZSBwcm9wb3Nl ZCDigJxzb2x1dGlvbnPigJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLi gJ0gaW4gdGhlIG5vcm1hbCB3YXksIG9yIHJlcXVpcmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1h a2UgcHJldmlvdXNseSBzaW1wbGUgdGhpbmdzIHVubmVjZXNzYXJpbHkgY29tcGxleC4gIFllcywg dGhlbiB0aGUgcmVzdWx0IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1dCBh IGNvbnNlcXVlbmNlIG9mIHRoaXMgaXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxkIGhh dmUgdG8gYmUgdXNlZCwgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiAgVGhlIG1v cmUgdW53aWVsZHkgd2UgbWFrZSBpdCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVs b3BlcnMgYXJlIHRvIGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuICBLZWVw aW5nIGl0IHNpbXBsZSBpcyB0aGUga2V5IHRvIGFkb3B0aW9uLiAgU3RhbmRhcmRzIGFyZSBvbmx5 IHVzZWZ1bCBpZiB0aGV5IGFyZSBhY3R1YWxseSB1c2VkLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFtt YWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE0NClRv OiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVz Y3VAZ29vZ2xlLmNvbT4+OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NCkNjOiBJRCBF dmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBU b2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KRWNob2luZyBNYXJpdXPi gJlzIHF1ZXN0aW9uOiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieSDigJxpbnRlbmTi gJ0/DQoNClRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3 b3VsZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJv cGVydHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBhbmQg dGhhdCBhIHJlY2lwaWVudCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRv IGFjY2VwdCBhIEpXVCBiZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4gc29tZSBjb250ZXh0Lg0KDQot LQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9t OiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1 QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpEYXRlOiBUdWVzZGF5 LCBKdW5lIDEzLCAyMDE3IGF0IDExOjA1IEFNDQpUbzogSGVuayBCaXJraG9seiA8aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZT4+DQpDYzogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOmlkLWV2ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9u IGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoN Ck9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHogPGhlbmsuYmly a2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9m ZXIuZGU+PiB3cm90ZToNCkFuZCBhIDJuZCBxdWVzdGlvbi4NCg0KV2hhdCBzZW1hbnRpY3Mgd291 bGQgInVzYWdlIiBwcm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICJpbnRlbmQi LCAiYXVkaWVuY2UiLCBhbmQgInNjb3BlIj8NCg0KImF1ZCIgKGF1ZGllbmNlKSBzcGVjaWZpZXMg dGhlIHRhcmdldCBjbGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9r ZW4gdG8gYXV0aG9yaXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBz ZWN1cml0eSBldmVudD8pDQoNCiJzY29wZSIgaXMgbm90IHVzZWQgYnkgU0VULg0KDQpJIGRvbid0 IGtub3cgd2hhdCBkbyB5b3UgbWVhbiBieSAiaW50ZW5kIiAob3IgaW50ZW50KT8NCg0KDQoNCg0K SGVuaw0KDQpPbiAwNi8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSB3cm90ZToNClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyIQ0KDQpJIHRoaW5rIHRo ZSBhc3N1bXB0aW9ucyBpbmhlcmVudCBpbiAzLjkgYXJlIGZsYXdlZDoNCg0KwrdXZSBjYW7igJl0 IGd1YXJhbnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4 Y2x1c2l2ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5k IGVuZm9yY2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xh aW3igJ0gYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMg Y2Fu4oCZdCBiZSBtaXN0YWtlbiBmb3IgSldUcyBmcm9tIGEgY3VycmVudCBzcGVjLg0KDQrCt0l0 IGlzIHVucmVhbGlzdGljIHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRoZXJlIHRvIHRoZSDi gJxkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPigJ0gcnVsZS4gV2hl dGhlciBtYW5kYXRlZCBieSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVycyB3aWxsIGlnbm9y ZSB0aGlzIGJlY2F1c2UgbWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhhbiBtYW5hZ2luZyBO IGRpZmZlcmVudCBrZXlzLg0KDQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBj bGFpbXMuDQoNCisxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVy IHBhcmFtZXRlci4NCg0KLS0NCg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQpJZGVudGl0 eSBTZXJ2aWNlcw0KDQoqRnJvbTogKklkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQoq RGF0ZTogKk1vbmRheSwgSnVuZSAxMiwgMjAxNyBhdCAzOjE4IFBNDQoqVG86ICpNYXJpdXMgU2N1 cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bT4+DQoqQ2M6ICpBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdv b2dsZS5jb20+PiwgIm1hdGFrZSwgbm92IiA8bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFr ZS5qcD4+LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 aWQtZXZlbnRAaWV0Zi5vcmc+PiwgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyDQoNCkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMgb2YgZGlz Y3Vzc2lvbiBvbiB3aGF0IHNob3VsZCBiZSBpbiAzLjkuDQoNCk9uIE1vbiwgSnVuIDEyLCAyMDE3 IGF0IDM6MTUgUE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPiA8bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTxt YWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4+IHdyb3RlOg0KDQogICAgVGhhbmtzIGZvciB0 aGUgcG9pbnRlciBEaWNrLCB2ZXJ5IGdvb2QgdGltaW5nIDotKQ0KDQogICAgVGhlIGlzc3VlIGlz IGRlc2NyaWJlZCBieSAiMi43LiBDcm9zcy1KV1QgQ29uZnVzaW9uIiBhbmQgdGhlDQogICAgbWl0 aWdhdGlvbiBpcyBpbiAiMy45LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZlIFZhbGlkYXRpb24gUnVs ZXMgZm9yDQogICAgRGlmZmVyZW50IEtpbmRzIG9mIEpXVHMiLCBzcGVjaWZpY2FsbHkgIlVzZSBk aWZmZXJlbnQgc2V0cyBvZg0KICAgIHJlcXVpcmVkIGNsYWltcy4uLiIsICJVc2UgZGlmZmVyZW50 IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZg0KICAgIEpXVHMuIiBhbmQgIlVzZSBkaWZmZXJl bnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuIi4NCg0KICAgIEkgc3RpbGwg dGhpbmsgdGhhdCBhICJ0eXBlIiBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFu ZA0KICAgIHNhZmV0eS4NCg0KDQogICAgTWFyaXVzDQoNCiAgICBPbiBUaHUsIEp1biA4LCAyMDE3 IGF0IDk6NTkgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbT4NCiAgICA8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0 bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+PiB3cm90ZToNCg0KICAgICAgICBZYXJvbiwgTWlrZSBh bmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVA0KICAgICAgICBodHRwOi8vc2Vs Zi1pc3N1ZWQuaW5mby8/cD0xNjkwPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwLTNBX19zZWxmLTJEaXNzdWVkLmluZm9fLTNGcC0zRDE2OTAmZD1Ed01HYVEm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3 NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1hN1h2WjVqVGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBk c0RrSVRaTWNVSVVRJmU9Pg0KDQogICAgICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTowMiBQ TSBBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+ DQogICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUu Y29tPj4+IHdyb3RlOg0KDQogICAgICAgICAgICBJIHdhcyBpbml0aWFsbHkgYSBmYW4gb2Yga2Vl cGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bw0KICAgICAgICAgICAgaWQgdG9rZW5zIGJ1 dCBJIG5vdyB0aGluayB0aGlzIGlzIGEgYmV0dGVyIHBsYW4uDQoNCiAgICAgICAgICAgIE9uIFRo dSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBtYXRha2UsIG5vdiA8bm92QG1hdGFrZS5qcDxtYWls dG86bm92QG1hdGFrZS5qcD4NCiAgICAgICAgICAgIDxtYWlsdG86bm92QG1hdGFrZS5qcDxtYWls dG86bm92QG1hdGFrZS5qcD4+PiB3cm90ZToNCg0KICAgICAgICAgICAgICAgICsxIGVzcGVjaWFs bHkgZm9yICJ0eXBlIg0KDQogICAgICAgICAgICAgICAgMjAxNy0wNi0wOSAxMDozMiBHTVQrMDk6 MDAgUGhpbCBIdW50IChJRE0pDQogICAgICAgICAgICAgICAgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4gPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pj46DQoNCiAgICAgICAgICAgICAgICAgICAg KzENCg0KICAgICAgICAgICAgICAgICAgICBQaGlsDQoNCg0KICAgICAgICAgICAgICAgICAgICAg PiBPbiBKdW4gOCwgMjAxNywgYXQgNjoyOCBQTSwgTWFyaXVzIFNjdXJ0ZXNjdQ0KICAgICAgICAg ICAgICAgICAgICA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2ds ZS5jb20+DQogICAgICAgICAgICAgICAgICAgIDxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29t PG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQogICAgICAgICAgICAgICAg ICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcHJv cG9zYWxzIG9uIGhvdyB0bw0KICAgICAgICAgICAgICAgICAgICBkaXN0aW5ndWlzaCBTRVRzIGZy b20gSWQgVG9rZW5zIGFuZCBBY2Nlc3MgVG9rZW5zIGluDQogICAgICAgICAgICAgICAgICAgIHN1 Y2ggYSB3YXkgdGhhdCBuYWl2ZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3QNCiAgICAgICAgICAg ICAgICAgICAgY29uZnVzZSBvbmUgZm9yIHRoZSBvdGhlciBhbmQgb3BlbiB1cCBzZWN1cml0eQ0K ICAgICAgICAgICAgICAgICAgICB2dWxuZXJhYmlsaXRpZXMuDQogICAgICAgICAgICAgICAgICAg ICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoZXJlIGlzIGFsc28gYW5vdGhlciBpbXBvcnRh bnQgcmVxdWlyZW1lbnQ6IHRoZQ0KICAgICAgICAgICAgICAgICAgICBTRVQgaXNzdWVyIGluIHNv bWUgY2FzZXMgbXVzdCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUNCiAgICAgICAgICAgICAgICAgICAg InN1YiIgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcgU0VUcw0KICAg ICAgICAgICAgICAgICAgICB0byBhbiBJZFAuDQogICAgICAgICAgICAgICAgICAgICA+DQogICAg ICAgICAgICAgICAgICAgICA+IFdpdGggdGhlc2UgcmVxdWlyZW1lbnRzIGluIG1pbmQgSSBwcm9w b3NlIHRoZQ0KICAgICAgICAgICAgICAgICAgICBmb2xsb3dpbmc6DQogICAgICAgICAgICAgICAg ICAgICA+IC0gYm90aCAic3ViIiBhbmQgImlzcyIgdG8gYmUgZGVmaW5lZCBhdCB0aGUgZXZlbnQN CiAgICAgICAgICAgICAgICAgICAgbGV2ZWwNCiAgICAgICAgICAgICAgICAgICAgID4gLSAiaXNz IiBhdCBldmVudCBsZXZlbCBhbmQgYXQgdG9wIFNFVCBsZXZlbCBjYW4NCiAgICAgICAgICAgICAg ICAgICAgYmUgZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAgICA+IC0gImlzcyIgYW5kICJz dWIiIGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAg YWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQNCiAgICAgICAgICAgICAgICAgICAgID4gLSAi c3ViIiBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBTRVQNCiAgICAgICAgICAgICAg ICAgICAgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFzZSBub3Rl DQogICAgICAgICAgICAgICAgICAgICJzaG91bGQiIGFuZCBub3QgIm11c3QiDQogICAgICAgICAg ICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRoaXMgc29sdXRpb24gYWxzbyBh bGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgZGVmaW5l IGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNsYWltcw0KICAgICAgICAgICAgICAg ICAgICByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFuZA0KICAg ICAgICAgICAgICAgICAgICBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUgYXQgdGhlIGV2 ZW50IGxldmVsDQogICAgICAgICAgICAgICAgICAgIHRoZXJlIHdpbGwgYmUgbm8gY29sbGlzaW9u cyBvciBhbWJpZ3VpdHkuDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAg ICAgICA+IEFub3RoZXIgcHJvcG9zYWwgKHdoaWNoIEkgc3VwcG9ydGVkKSB3YXMgdG8NCiAgICAg ICAgICAgICAgICAgICAgZGVmaW5lIGEgY29tcG9zaXRlICJhdWQiIGNsYWltLiBUaGlzIGlzIG5v dCBzb2x2aW5nDQogICAgICAgICAgICAgICAgICAgIHRoZSByZXF1aXJlbWVudCBmb3IgYSBkaXN0 aW5jdCAgU0VUIGlzc3Vlci4gQWxzbywNCiAgICAgICAgICAgICAgICAgICAgaGF2aW5nIHRoZSBz YW1lIGNsYWltIG5hbWUgaGF2aW5nIGRpZmZlcmVudCBzeW50YXgNCiAgICAgICAgICAgICAgICAg ICAgaW4gZGlmZmVyZW50IHRva2VuIHR5cGVzIGNvdWxkIGxlYWQgdG8gY29uZnVzaW9uLg0KICAg ICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBBbmQgeWV0IGFub3Ro ZXIgcHJvcG9zYWwgd2FzIHRvIGludHJvZHVjZSBhIG5ldw0KICAgICAgICAgICAgICAgICAgICBj bGFpbSBmb3IgSldUcyB0aGF0IGRlZmluZXMgYSAidHlwZSIuIFRoaXMgaXMgbm90DQogICAgICAg ICAgICAgICAgICAgIHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwgYW5kIGl0IGFsc28gaXMg bm90DQogICAgICAgICAgICAgICAgICAgIHNvbHZpbmcgdGhlIGRpc3RpbmN0IGlzc3VlciByZXF1 aXJlbWVudCwgYnV0IEkgdGhpbmsNCiAgICAgICAgICAgICAgICAgICAgdGhpcyBpcyBzb21ldGhp bmcgdGhlIEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5DQogICAgICAgICAgICAgICAgICAgIGNv bnNpZGVyLg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBU aG91Z2h0cz8NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4g TWFyaXVzDQoNCiAgICAgICAgICAgICAgICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnQg bWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgICAgICA+IElkLWV2ZW50QGlldGYub3JnPG1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAg ICAgICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPUptdXV0Qng0REFQcDc0QVVMY3gySV9q dmdYenVhNm1pUmlIcVdnZnhxbWcmcz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14 UFFGSkxoeFdJJmU9DQoNCiAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnQg bWFpbGluZyBsaXN0DQogICAgICAgICAgICAgICAgICAgIElkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQt MkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNs ajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllW SVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgICAgICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAg ICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgICAgIElkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNz S0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAgICAgLS0N CiAgICAgICAgICAgIEFkYW0gRGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHxhZGF3ZXNAZ29v Z2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+DQogICAgICAgICAgICA8bWFpbHRvOmFk YXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4+IHwrMSA2NTAtMjE0LTI0 MTA8dGVsOiUyQjElMjA2NTAtMjE0LTI0MTA+DQogICAgICAgICAgICA8dGVsOig2NTApJTIwMjE0 LTI0MTA8dGVsOiUyODY1MCUyOSUyMDIxNC0yNDEwPj4NCg0KICAgICAgICAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgIElkLWV2 ZW50IG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4+DQogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3 TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2ht UWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUti OXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgLS0NCiAgICAgICAgU3Vic2NyaWJlIHRv IHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEm Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3 NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFP VVgyWE1ZQmVyVjgwJmU9Pj4gbWFpbCBsaXN0IHRvDQogICAgICAgIGxlYXJuIGFib3V0IHByb2pl Y3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCi0tDQoNClN1YnNjcmliZSB0byB0aGUgSEFSRFRX QVJFIDxodHRwOi8vaGFyZHR3YXJlLmNvbS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAw WV8zelJvYWkxMTVjJnM9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4 MCZlPT4+IG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24h DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNX V3MmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZl bnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJ VFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0 LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdN U1dXcyZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJ Q0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTVi aVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1R bDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5 dXlnN29NVTdUbUdNU1dXcyZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkLWV2ZW50DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCg0KSWQtZXZlbnRAaWV0Zi5v cmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg0KDQo= --_000_CY4PR21MB05049568082B6C260AFDE06AF5DA0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu bTI4ODgzMTczNjI2NjgyMDY3NDVnbWFpbC1tMjEzMDc4Mzk4ODk0NTI0NjUzNW00NjM5NzE4ODk4 NjQ3NzQ5NjY4bTQ0NDE3MTQ0NDg3MjEwNzcwNTdtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3Rw YXJhZ3JhcGgsIGxpLm0yODg4MzE3MzYyNjY4MjA2NzQ1Z21haWwtbTIxMzA3ODM5ODg5NDUyNDY1 MzVtNDYzOTcxODg5ODY0Nzc0OTY2OG00NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1 NzAzMTJtc29saXN0cGFyYWdyYXBoLCBkaXYubTI4ODgzMTczNjI2NjgyMDY3NDVnbWFpbC1tMjEz MDc4Mzk4ODk0NTI0NjUzNW00NjM5NzE4ODk4NjQ3NzQ5NjY4bTQ0NDE3MTQ0NDg3MjEwNzcwNTdt OTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8y ODg4MzE3MzYyNjY4MjA2NzQ1Z21haWwtbTIxMzA3ODM5ODg5NDUyNDY1MzVtNDYzOTcxODg5ODY0 Nzc0OTY2OG00NDQxNzE0NDQ4NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFy YWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODEwNzYz ODQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDYzMjk4OTMwO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MjY1Njk4MzEyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDMx MjI3OTcwO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6OTE5NzQ5NDUzOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo4MDk2Nzg4MTI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28t bGlzdC1pZDoxMzE4MzQxODE1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTY2MjQxOTkwO30N CkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTQ3MjEzNTkwNDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjAxMDcwNzE4O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6 MTUyMDg1MDExOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODcyNDMwMDQ0O30NCkBsaXN0IGw1 OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDU6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDYNCgl7bXNvLWxpc3QtaWQ6MTk2NzYxNjAwNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTcyODU5MjQ3NDt9DQpAbGlzdCBsNjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw2OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjE5NzUyMDc1 NTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTA1NzczMDA2O30NCkBsaXN0IGw3OmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5NYXJpdXMsIHlvdSB3cm90ZSDigJw8L3NwYW4+QlRXLCB5b3UgbmV2ZXIg b2ZmZXJlZCBhIHNvbHV0aW9uIHRvIHRoZSBSUCBpc3N1ZWQgU0VUcyBwcm9ibGVtIE1Ja2UuIENh biB5b3UgcGxlYXNlIGRvIHRoYXQ/PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPuKAnSZuYnNw OyBJIHRob3VnaHQgd2UgYWxyZWFkeSBoYWQgYSB3ZWxsLXVuZGVyc3Rvb2Qgc29sdXRpb24gdG8g dGhhdCwNCiBidXQgSeKAmWxsIHJlcGVhdCBpdCBoZXJlLiZuYnNwOyBJ4oCZbGwgZ2l2ZSB0aGUg ZXhhbXBsZSBhc3N1bWluZyB0aGF0IHRoZSBldmVudCBpcyBhYm91dCBhbiBPcGVuSUQgQ29ubmVj dCBhY2NvdW50IHRoYXQgaXMgbmFtZWQgYnkgYW4gKOKAnGlzc+KAnSwg4oCcc3Vi4oCdKSBwYWly LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SWYgdGhlIFJQIGlzIGlzc3Vp bmcgdGhlIFNFVCwgaXQgYWxyZWFkeSBtdXN0IGlkZW50aWZ5IGl0c2VsZiB1c2luZyB0aGUgdG9w LWxldmVsIOKAnGlzc+KAnSBjbGFpbSwgcGVyIHRoZSBTRVQgc3BlYy4mbmJzcDsgVGhlIE9wZW5J RCBDb25uZWN0IGFjY291bnQgdGhhdCBpcyB0aGUgc3ViamVjdCBvZiB0aGUgZXZlbnQgd291bGQg Y29udGFpbiB0aGUgKOKAnGlzc+KAnSwg4oCcc3Vi4oCdKSB2YWx1ZXMNCiBpbiB0aGUgZXZlbnQg cGF5bG9hZC4mbmJzcDsgSW4gZmFjdCwgSeKAmW0gYXNzdW1pbmcgdGhhdCB0aGF0IHdvdWxkIGJl IHRoZSBjYXNlIGZvciBhbGwgUklTQyBldmVudHMgKGFuZCBwb3NzaWJseSBmb3Igc29tZSBvdGhl ciBldmVudCBwcm9maWxlcyB0b28pLiZuYnNwOyBJ4oCZbSBjb21wbGV0ZWx5IHN1cHBvcnRpdmUg b2YgdGhhdCBjaG9pY2UgaWYgbWFkZSBieSBhIHByb2ZpbGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5CdXQgdGhlcmUgd2lsbCBhbHNvIGJlIHVzZSBjYXNlcyDigJMgcG9z c2libHkgbm9uLWlkZW50aXR5IHVzZSBjYXNlcywgaW4gd2hpY2ggdGhlIHRoaW5nIGJlaW5nIG9w ZXJhdGVkIG9uIGRvZXNu4oCZdCBoYXZlIGFueSBpc3N1ZXIgdmFsdWUgb3IgaW4gd2hpY2ggdGhl IGV2ZW50IGlzc3VlciBpcyBhbHdheXMgdGhlIHNhbWUgYXMgdGhlIGlzc3VlciBmb3IgdGhlIHRo aW5nDQogYmVpbmcgb3BlcmF0ZWQgb24uJm5ic3A7IFRyeWluZyB0byBpbXBvc2UgdGhlIGNob2lj ZXMgbWFkZSBieSBvbmUgU0VUIHByb2ZpbGUgb250byBhbGwgb3RoZXJzLCB0aG91Z2gsIGFzc3Vt ZXMgd2Uga25vdyB3YXkgbW9yZSBhYm91dCB0aGVpciB1c2UgY2FzZXMgdGhhbiB3ZSBhY3R1YWxs eSBkby4mbmJzcDsgV2UgbmVlZCB0byBsZWF2ZSB0aGVpciBjb252ZW50aW9ucyB1cCB0byB0aGVt IOKAkyBqdXN0IGxpa2UgSldUIGxlZnQgY2xhaW1zIGNvbnZlbnRpb25zIHVwDQogdG8gcHJvZmls ZXMuJm5ic3A7IFRoYXTigJlzIHdoeSBpdOKAmXMgZ2VuZXJhbC1wdXJwb3NlIGFuZCBiZWluZyB3 aWRlbHkgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNYXJpdXMgU2N1cnRlc2N1IFttYWlsdG86 bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVu ZSAyMSwgMjAxNyA0OjIwIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNLkxpemFyQE9DRyAmbHQ7 bS5saXphckBvcGVuY29uc2VudGdyb3VwLmNvbSZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlICZsdDtyaWNoYW5uYUBhbWF6b24uY29tJmd0OzsgSGVuayBCaXJraG9seiAmbHQ7aGVuay5i aXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSZndDs7IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJA bWl0LmVkdSZndDs7IFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDs7 IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0OzsNCiBQaGls IEh1bnQgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQg ZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEp1biAyMSwgMjAxNyBhdCAxOjE5IFBNLCBNaWtlIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NYXJpdXMsIHRoZSBxdWVzdGlvbiDigJw8L3NwYW4+ RG8geW91IGhhdmUgZXhhbXBsZXMgb2YgdXNlIGNhc2VzIHRoYXQgY2Fubm90IGhhbmRsZSBzdWIg YXQgdGhlIGV2ZW50IGxldmVsPzxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7igJ0gaXMgbm8g bW9yZSB1c2VmdWwNCiB0aGFuIHRoZSBxdWVzdGlvbiDigJxEbyB5b3UgaGF2ZSBleGFtcGxlcyBv ZiB1c2UgY2FzZXMgdGhhdCBjYW5ub3QgaGFuZGxlIOKAmHN1YuKAmSBzcGVsbGVkIGFzIHRoZSBM YXRpbiB3b3JkIOKAmHN1YmllY3R1beKAmT/igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBkaXNhZ3JlZS4gSWYgc3ViIGF0IHRoZSBldmVudCBsZXZlbCBpcyBhbiBpc3N1ZSB0aGVuIGxl dCdzIGJlIGNvbmNyZXRlIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7IFllcywgYXBwbGljYXRpb25zIGNvdWxkIGFsd2F5cyB3 b3JrIGFyb3VuZCB0aGUgaW5jb252ZW5pZW5jZXMgaW50cm9kdWNlZCBieSBhcmJpdHJhcnkgY2xh aW0gcmVuYW1pbmcgb3IgcmVwb3NpdGlvbmluZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBpcyBub3QgYW4gYXJiaXRyYXJ5IHJlcG9zaXRpb25pbmcsIHRoZSByZWFzb25zIGEgdmVy eSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PmJ1dCB0aGV5IHNob3VsZG7igJl0IGhhdmUgdG8uJm5ic3A7IEl0IGp1c3QgYWRkcyBjb21wbGV4 aXR5IGFuZCB3aWxsIGhpbmRlciBhZG9wdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWlub3IgY29tcGxleGl0eSBhZGRlZCwgaWYgYXQgYWxsLiBUaGUgb25seSBkb3duc2lkZSBpcyB0 aGUgc2xpZ2h0bHkgbGFyZ2VyIHNpemUgb2YgU0VUcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdCBzZWVtcyB0 byBtZSB0aGF0IHlvdXIgbW90aXZhdGlvbiBmb3IgYWx3YXlzIGhhdmluZyDigJxzdWLigJ0gaW4g dGhlIGV2ZW50IHBheWxvYWQsIHJhdGhlciB0aGFuIGEgbm9ybWFsIGNsYWltLCBpcyB0aGF0IHRo YXTigJlzIGhvdyB5b3UgdGhpbmsgUklTQyBldmVudHMNCiB3aWxsIGJlIHN0cnVjdHVyZWQsIGFu ZCB0aGF0IHlvdSB3YW50ICo8Yj5hbGw8L2I+KiBldmVudHMgdG8gYWxzbyB1c2UgdGhlIFJJU0Mg ZXZlbnQgc3RydWN0dXJpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFzIGFi c29sdXRlbHkgbm90aGluZyB0byBkbyB3aXRoIFJJU0MgaW4gcGFydGljdWxhci4gQm90aCB0aGUg Y29uZnVzaW9uIHByb2JsZW0gYW5kIHRoZSBSUCBpc3N1ZWQgU0VUcyBhcmUgZ2VuZXJpYyBTRVQg cHJvYmxlbXMgdGhhdCBuZWVkIHRvIGJlIHNvbHZlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlRXLCB5b3UgbmV2ZXIgb2ZmZXJlZCBhIHNv bHV0aW9uIHRvIHRoZSBSUCBpc3N1ZWQgU0VUcyBwcm9ibGVtIE1Ja2UuIENhbiB5b3UgcGxlYXNl IGRvIHRoYXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDsgVG8gbXkgd2F5IG9mIHRoaW5raW5nLCBpZiB5b3UgcmVhbGx5IGJlbGlldmUgdGhh dCB5b3Ugc2hvdWxkIGJlIGFza2luZyB0aGUgU0VUIHNwZWMgdG8gYmUgd2l0aGRyYXduIGZyb20g dGhlIElFVEYgYW5kIG9ubHkgZGVmaW5lIFJJU0MgZXZlbnRzIGluIHRoZQ0KIFJJU0Mgd29ya2lu ZyBncm91cC4mbmJzcDsgQnV0IGluIGZhY3QsIHJlcXVpcmluZyBhbGwgZXZlbnRzIHRvIGZvbGxv dyB0aGUgUklTQyBjb252ZW50aW9ucyBtYWtlcyBubyBtb3JlIHNlbnNlIHRoYW4gcmVxdWlyaW5n IGFsbCBKV1RzIHRvIGJlIElEIFRva2Vucy4mbmJzcDsgVGhhdCB3b3VsZCBoYXZlIG1hZGUgSldU cyB1c2VsZXNzIGZvciBtYW55IHVzZSBjYXNlcy4mbmJzcDsgUHJvcG9zaW5nIHRvIGxpbWl0IGNs YWltcyB1c2FnZSBpbiBTRVRzIHdvdWxkIGxpa2V3aXNlDQogbWFrZSB0aGVtIGluYXBwbGljYWJs ZSBmb3IgbWFueSBub24tUklTQyB1c2UgY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+V2UgaGF2ZSBhIHBvdGVudGlhbCBzdWNjZXNzIG9uIG91ciBoYW5kcy4m bmJzcDsgTGV04oCZcyBub3Qgc2NyZXcgaXQgdXAgYnkgbWFraW5nIGl0IHVubmVjZXNzYXJpbHkg Y29tcGxpY2F0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUsIGxldCdzIHNvbHZl IGFsbCBvcGVuIGlzc3VlcyBmaXJzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8yODg4MzE3MzYyNjY4MjA2NzQ1X19NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBNYXJpdXMg U2N1cnRlc2N1IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IDE6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IDxh IGhyZWY9Im1haWx0bzpNLkxpemFyQE9DRyI+TS5MaXphckBPQ0c8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86bS5saXphckBvcGVuY29uc2VudGdyb3VwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm0ubGl6 YXJAb3BlbmNvbnNlbnRncm91cC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDs7IEhlbmsgQmlya2hv bHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0 YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7Ow0K IEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdl dD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OzsgWWFyb24gU2hlZmZlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9u Zi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBo cmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBp ZXRmLm9yZzwvYT4mZ3Q7Ow0KIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0 OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBU b2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFdlZCwgSnVuIDIxLCAyMDE3IGF0IDExOjQ2IEFNLA0KPGEgaHJlZj0ibWFpbHRvOk0u TGl6YXJAT0NHIiB0YXJnZXQ9Il9ibGFuayI+TS5MaXphckBPQ0c8L2E+ICZsdDs8YSBocmVmPSJt YWlsdG86bS5saXphckBvcGVuY29uc2VudGdyb3VwLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm0ubGl6 YXJAb3BlbmNvbnNlbnRncm91cC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+ RldJVyAtIEkgYWdyZWUgd2l0aCBNaWtlIHRoYXQgcHV0dGluZyByZXN0cmljdGlvbnMgb24gdGhl ICZxdW90O3N1YiZxdW90OyBjbGFpbSB1c2FnZSB3b3VsZCB1bm5lY2Vzc2FyaWx5DQogY29tcGxp Y2F0ZSBTRVRzIGZvciBzb21lIHVzZSBjYXNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdWIg aXMgZGVmaW5lZCBhcyBvcHRpb25hbCBpbiBKV1QsIHNvIHRlY2huaWNhbGx5IHdlIGFyZSBub3Qg YWRkaW5nIGFueSByZXN0cmljdGlvbnMuIERvIHlvdSBoYXZlIGV4YW1wbGVzIG9mIHVzZSBjYXNl cyB0aGF0IGNhbm5vdCBoYW5kbGUgc3ViIGF0IHRoZSBldmVudCBsZXZlbD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2JhY2tncm91bmQ6d2hpdGUiPkl0cyBh IGxvdCBlYXNpZXIgdG8gYWRkIHRvIGEgc3BlYyBhbmQgdmVyeSZuYnNwO2RpZmZpY3VsdCZuYnNw OyhpZiBub3QgaW1wb3NzaWJsZSkgdG8gcmV0cmFjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBhZ3JlZS4gSSBkb24ndCB0aGluayBhbnl0aGluZyBpcyByZXRyYWN0 ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BZ2Fpbiwgc2VlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUx OSNzZWN0aW9uLTQuMS4yIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxhc3Qgc2VudGVuY2Ugb2YgNC4xLjIgc3Rh dGVzICZxdW90O1VzZSBvZiB0aGlzIGNsYWltIGlzIE9QVElPTkFMLiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtiYWNrZ3JvdW5kOndoaXRlIj5JbiB0aGlz IHJlZ2FyZCwga2VlcGluZyBpdCBzaW1wbGUgaXMgY3JpdGljYWwgZm9yIGJyb2FkIGFkb3B0aW9u LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2JhY2tncm91bmQ6 d2hpdGUiPk1hcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDE5IEp1biAyMDE3 LCBhdCAxNjo1NSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVz Y3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk1pa2UsIGFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBkZWZpbmUgU0VUcyBpbiBzdWNoIGEgd2F5 IHRoYXQgdGhleSB3aWxsIG5vdCB3b3JrIGZvciBSSVNDPyBBIHRvcCBsZXZlbCBpc3MmIzQzO3N1 YiBpcyBjbGVhcmx5IG5vdCB3b3JraW5nIGZvciBSSVNDLCBhbmQgbWF5IG5vdCB3b3JrIGZvciBs b2dvdXQgZWl0aGVyIGlmDQogeW91IGFsbG93IGxvZ291dCB0byBiZSBpbml0aWF0ZWQgZnJvbSBh biBSUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+TWFyaXVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSnVuIDE5LCAyMDE3IGF0IDI6MjcgUE0sIE1pa2Ug Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5NYXJpdXMsIHRoZXJl4oCZcyBub3RoaW5nIHN0b3BwaW5nIHlvdSAo b3IgdGhlIFJJU0Mgd29ya2luZyBncm91cCBvciBvdGhlciBwcm9maWxlcykgZnJvbSBkZWZpbmlu ZyBldmVudHMgdGhhdCBjYW4gYmUgc2VudCBmcm9tIFJQcyB0byBJZFBzIG5vdywgd2l0aG91dA0K IGFueSBjaGFuZ2VzIHRvIHRoZSBTRVQgc3BlYy4mbmJzcDsgU3BlY2lmeSB0aGUgY2xhaW1zIHlv dSB3YW50IHRvIHVzZSwgYW5kIHlvdeKAmXJlIGdvbGRlbi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5CdXQgaXQgd291bGQgYmUgY291bnRlcnByb2R1Y3RpdmUgdG8g cmVxdWlyZSBhbGwgb3RoZXIgU0VUcyB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgeW91ciBz cGVjaWZpYyBwcm9maWxlLiZuYnNwOyBUaGVyZSBhcmUgc2ltcGxlciB1c2UgY2FzZXMgdGhhdCBj YW4NCiB1c2UgY2xhaW1zIGluIHNpbXBsZXIgd2F5cy4mbmJzcDsgVHJ5aW5nIHRvIG1ha2UgdGhl IHNpbXBsZSB1c2UgY2FzZXMgYmUgY29tcGxleCB3aWxsIGhhdmUgdGhlIHNpZGUgZWZmZWN0IG9m IGxpbWl0aW5nIHRoZSBhZG9wdGlvbiBvZiB0aGUgc3BlYywgd2hpY2ggd291bGRu4oCZdCBiZSBn b29kIGZvciBhbnlvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ SWYgc3VjY2Vzc2Z1bCwgU0VUcyB3aWxsIGhhdmUgbWFueSBkaWZmZXJlbnQgcHJvZmlsZXMuJm5i c3A7IFRoYXTigJlzIGEgc2lnbiBvZiBzdWNjZXNzIOKAkyBub3QgYSBzaWduIG9mIHdlYWtuZXNz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzI4ODgzMTczNjI2NjgyMDY3NDVfbV8y MTMwNzgzOTg4OTQ1MjQ2Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+ IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTksIDIwMTcgMTE6NTggQU08YnI+DQo8Yj5Ubzo8 L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gWWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9u Zi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7OyBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1 IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs7IFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OzsNCiBIZW5rIEJpcmtob2x6 ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFy Z2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0OzsgSUQg RXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0OzsgUGhpbCBIdW50ICZs dDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5w aGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZl bnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBT RVQgaXNzdWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBKdW4gMTcsIDIwMTcg YXQgMjowNiBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPknigJltIHNvcnJ5IHRvIGJlIHNsb3cg cmVwbHlpbmcgdG8gc29tZSBtZXNzYWdlcyBpbiB0aGlzIHRocmVhZC4mbmJzcDsgSSBoYXZlIGEg bG90IG9mIG90aGVyIHRoaW5ncyBvbiBteSBwbGF0ZSwgYnV0IEkgd2lsbCB0YWtlIHRoZSB0aW1l IG5vdyB0byByZXBseSwgYmVjYXVzZQ0KIEkgd2hvbGVoZWFydGVkbHkgZGlzYWdyZWUgd2l0aCBz b21lIG9mIHRoZSBzdGF0ZW1lbnRzIGJlbG93IGFuZCBiZWxpZXZlIGl0IHdvdWxkIGJlIHNldmVy ZWx5IGhhcm1mdWwgdG8gdGhlIHNwZWNpZmljYXRpb24gYW5kIGl0cyBhZG9wdGlvbiB0byBhY3Qg dXBvbiB0aGVtLiZuYnNwOyBTcGVjaWZpY2FsbHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojMDAyMDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZlbDEgbGZv MSI+DQpJIGRpc2FncmVlIHRoYXQgc3BlY2lmaWMgcnVsZXMgc2hvdWxkIGJlIG1hZGUgZm9yIHRo ZSDigJxzdWLigJ0gY2xhaW0uJm5ic3A7IENsYWltcyB1c2FnZSBuZWVkcyB0byBiZSB1cCB0byB0 aGUgYXBwbGljYXRpb24uJm5ic3A7IEkga25vdyB0aGF0IG1hbnkgb3RoZXJzIGFncmVlIHdpdGgg bWUsIGJlY2F1c2UgdGhlIE9wZW5JRCBDb25uZWN0IHdvcmtpbmcgZ3JvdXAgZGVzaWduZWQgdGhl IGxvZ291dCB0b2tlbiBpbg0KPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Blbmlk LWNvbm5lY3QtYmFja2NoYW5uZWwtMV8wLTA0Lmh0bWwjTG9nb3V0VG9rZW4iIHRhcmdldD0iX2Js YW5rIj4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWJhY2tjaGFubmVs LTFfMC0wNC5odG1sI0xvZ291dFRva2VuPC9hPiAod2hpY2ggaXMgYWxzbyB1c2VkIGFzIGFuIGV4 YW1wbGUgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDEjc2VjdGlvbi0y PC9hPikgdG8gdXNlIHRoZSDigJxzdWLigJ0gY2xhaW0gaW4gdGhlIG5vcm1hbCB3YXkuJm5ic3A7 IFByb2hpYml0aW5nIHRoaXMgdXNhZ2Ugd291bGQgYmUgYSBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5 IGJyZWFraW5nIGNoYW5nZSDigJMgYXMgaXTigJlzIGltcG9zc2libGUgdG8gY29uZnVzZSBhIGxv Z291dCB0b2tlbiB3aXRoIGFuIElEIFRva2VuLCBmb3INCiByZWFzb25zIGFscmVhZHkgY2l0ZXMg aW4gdGhpcyB0aHJlYWQuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29sdmluZyB0aGUgY29u ZnVzaW9uIGlzIG9uZSBwcm9ibGVtLiBUaGUgb3RoZXIgcHJvYmxlbSBJIGtlZXAgbWVudGlvbmlu ZyBpcyBTRVRzIGlzc3VlZCBieSBhbiBSUCB0byBiZSBzZW50IHRvIGFuIElkUC4gSG93IGFyZSB3 ZSBzb2x2aW5nIHRoYXQgcHJvYmxlbSBNaWtlPyBJbiB0aGlzIGNhc2UgdGhlIHRvcA0KIGxldmVs IGlzcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgaXNzIG9mIHRoZSBzdWIsIGEgdG9wIGxldmVsIHN1 YiBpcyBub3QgcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5BbmQgSSBkb24ndCB3YW50IHRvIGRvd25wbGF5IHRoZSBjb25m dXNpb24gcHJvYmxlbSBlaXRoZXIuIEkgdGhpbmsgaXQgaXMgYSByZWFsIGNvbmNlcm4gYW5kIEkg dGhpbmsgYSBzb2xpZCBzb2x1dGlvbiBpcyBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgT3BlbklEIFdvcmtpbmcg R3JvdXAgZGVzaWduZWQgbG9nb3V0IHRva2VucyB3aXRob3V0IHNlY2V2ZW50IGluIG1pbmQuIEkg YWdyZWUgd2Ugc2hvdWxkIG5vdCByZWNrbGVzc2x5IGJyZWFrIGNvbXBhdGliaWxpdHksIGJ1dCB0 byBtZSBpdCBzZWVtcyBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6IzAwMjA2MDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzIiPg0K Jm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7 bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCihJIGFncmVlIHdpdGggdGhlIOKA nGlzc+KAnSBydWxlcyBhbHJlYWR5IGluIHBsYWNlIGF0IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LXRva2VuLTAxI3NlY3Rpb24tMi4xIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z ZWNldmVudC10b2tlbi0wMSNzZWN0aW9uLTIuMTwvYT4uJm5ic3A7IE5vIGZ1cnRoZXIg4oCcaXNz 4oCdIHJ1bGVzIGFyZSBuZWVkZWQuKTxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GdXJ0 aGVyIGlzcyBydWllcyBhcmUgYWJzb2x1dGVseSBuZWVkZWQgZm9yIHRoZSBSUCB0byBJZFAgY2Fz ZSBkZXNjcmliZWQgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzAw MjA2MDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KJm5ic3A7PG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwxIGxldmVsMSBsZm81Ij4NCkl04oCZcyBmaW5lIGZvciB0aGUg4oCcdHlw4oCdIGhlYWRl ciBwYXJhbWV0ZXIgdG8gYmUgdXNlZCBmb3Igc29tZSBwcm9maWxlcyB0byBkaWZmZXJlbnRpYXRl IGJldHdlZW4ga2luZHMgb2YgSldUcy4mbmJzcDsgSXRzIHVzZSBzaG91bGQgbm90IGJlIG1hbmRh dGVkIGluIHRoZSBTRVQgc3BlYy4mbmJzcDsgSSB3b3VsZCBvcHBvc2UgZHVwbGljYXRpbmcgdGhl IOKAnHR5cOKAnSBmdW5jdGlvbmFsaXR5IGJ5IGRlZmluaW5nIGFub3RoZXIgY2xhaW0gd2l0aCBh IGR1cGxpY2F0aXZlIG1lYW5pbmcuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdHlwIGNh biBiZSB1c2UgYW5kIG5vIG90aGVyIGNsYWltIGlzIG5lZWRlZCwgdGhlbiBsZXQncyB0YWxrIGFi b3V0IHRoYXQuIEkgZG8gdGhpbmsgU0VUIHNob3VsZCBtYW5kYXRlIGl0LiBJIGRvbid0IHVuZGVy c3RhbmQgd2h5IG5vdC4gQ2FuIHlvdSBwbGVhc2UgcHJvcG9zZSB3aXRoIGV4YW1wbGVzIGhvdw0K IGNhbiB0eXAgYmUgdXNlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDAy MDYwO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQombmJzcDs8bzpwPjwvbzpw PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDYgbGV2ZWwxIGxmbzciPg0KSeKAmWxsIGFsc28gcmVzcG9uZCB0byBBbm5hYmVsbGXigJlz IGFzc2VydGlvbiB0aGF0IOKAnE5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyIHVzZSB0 aGUgJnF1b3Q7bm9uY2XigJ0gY2xhaW0u4oCdJm5ic3A7IFRoaXMgcmVmbGVjdHMgYSBtaXN1bmRl cnN0YW5kaW5nLiZuYnNwOyBJdOKAmXMgdGhlICo8Yj52YWx1ZTwvYj4qIG9mIHRoZSBub25jZSB0 aGF0IHNlbGYtc2VjdXJlcyB0aGUgSldUIOKAkyBub3QgdGhhdCBhbnkg4oCcbm9uY2XigJ0gY2xh aW0gaXMgcHJlc2VudC4mbmJzcDsgQW55IGFuZCBhbGwNCiBKV1RzIGNhbiBzaW11bHRhbmVvdXNs eSB1c2Ug4oCcbm9uY2XigJ0gd2l0aG91dCBhbnkgcmlzayBvZiBjb25mbGljdCwgc2luY2UgdGhl IG5vbmNlIHZhbHVlIGlzIGEgY3J5cHRvZ3JhcGhpY2FsbHkgc2VjdXJlIHJhbmRvbSBudW1iZXIu PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBTRVRzIEkgY2Fubm90IHNlZSBob3cg dGhlIG5vbmNlIHZhbHVlIGlzIHVzZWZ1bC4gVGhhdCB2YWx1ZSBpcyBub3QgcGFzc2VkIGJhY2sg YW5kIGl0IGNhbm5vdCBiZSB2ZXJpZmllZC4gT25seSB0aGUgcHJlc2VuY2Ugb2YgdGhlIGNsYWlt IGNvdWxkIGhhdmUgc29tZSB1c2UsIGhpbnRpbmcgYXQgdGhlDQogdXNhZ2Ugb2YgdGhlIEpXVCwg YSB2ZXJ5IHdlYWsgc29sdXRpb24gdG8gdGhlIGNvbmZ1c2lvbiBwcm9ibGVtLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6IzAwMjA2MDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDcgbGV2ZWwx IGxmbzgiPg0KJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5X aWxsIHNvbWUgb2YgeW91IGJlIGF0IHRoZSBDbG91ZCBJZGVudGl0eSBTdW1taXQgbmV4dCB3ZWVr PyZuYnNwOyBJ4oCZZCBiZSBnbGFkIHRvIGhhdmUgaW4tcGVyc29uIGRpc2N1c3Npb25zIGFib3V0 IHRoZXNlIHRvcGljcyB0aGVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlAuUy4mbmJzcDsgRm9vZCBmb3Ig dGhvdWdodDombmJzcDsgUHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gKG9yIGFueSBv dGhlciBjbGFpbSkgb3IgZm9yY2luZyBpdCB0byBiZSBsb2NhdGVkIGluIGEgbm9uLXN0YW5kYXJk IGxvY2F0aW9uIG1ha2VzIGFib3V0IGFzIG11Y2gNCiBzZW5zZSBhcyBhcmJpdHJhcmlseSBzYXlp bmcgdGhhdCwgZm9yIGEgcGFydGljdWxhciBwcm9maWxlLCB0aGUgTGF0aW4gd29yZCBmb3Igc3Vi amVjdCDigJxzdWJpZWN0dW3igJ0gbXVzdCBiZSB1c2VkIGFzIHRoZSBjbGFpbSBuYW1lIGluc3Rl YWQgb2Yg4oCcc3Vi4oCdLiZuYnNwOyBZZXMsIGl0IHdpbGwgY29tcGxldGVseSBkaWZmZXJlbnRp YXRlIHRoaXMgcHJvZmlsZSBmcm9tIG90aGVycyBub3Qgc3BlbGxpbmcgdGhlIGNsYWltIG5hbWUg dGhpcyB3YXksIGJ1dCBpdA0KIHdvdWxkIGNlcnRhaW5seSBiZSBhbiBpbXBlZGltZW50IHRvIHRo ZSB1c2Ugb2Ygc3RhbmRhcmQgSldUIGxpYnJhcmllcyBhbmQgdG8gaW50ZXJvcGVyYWJpbGl0eS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIGRlZmluZSB0aGF0IHN1YiBtdXN0 IGJlIGF0IHRoZSBldmVudCBsZXZlbCB0aGVuIGl0IGlzIGF0IGEgc3RhbmRhcmQgbG9jYXRpb24s IEkgZG9uJ3Qgc2VlIHdoYXQgdGhlIGlzc3VlIGlzLiBUaGUgaW1wZWRpbWVudCB5b3UgbWVudGlv biBpcyB0aGUgYWN0dWFsIHNvbHV0aW9uLiBJIGRvbid0IHRoaW5rDQogdGhhdCBhIEpXVCBsaWJy YXJ5IHRoYXQgd2FzIHdyaXR0ZW4gZm9yIElkIFRva2VucyBzaG91bGQgYmUgdXNlZCB0byBwYXJz ZSBTRVRzLiBUaGUgbGlicmFyeSBoYXMgdG8gYmUgU0VUIGF3YXJlLCBpbiB3aGljaCBjYXNlIHRo ZSBldmVudCBsZXZlbCBpc3MmIzQzO3N1YiBpcyBub3QgYW4gaXNzdWUgYXQgYWxsLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+RnJvbTo8L2I+IFlhcm9uIFNoZWZmZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86eWFy b25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVuZSAxNywgMjAxNyAxOjQ1IFBN PGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hl ckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs7IE1hcml1 cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7 OyBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7 IEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1 bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZTwvYT4mZ3Q7Ow0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZn dDs7IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lv biBhbmQgZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5TbyB0byBzdW1tYXJpemUgd2hhdCBJJ20gc2VlaW5nIG9u IHRoaXMgdGhyZWFkOjxvOnA+PC9vOnA+PC9wPg0KPHA+RXZlcnlib2R5IGFncmVlcyB3aXRoIE1h cml1cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNwZWNpZmljIHJ1bGVzIGZvciAmcXVvdDtzdWIm cXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0aGF0IGNhbiBiZSBkZWZpbmVkIGluIHRoZSBTRVQg c3BlYy48bzpwPjwvbzpwPjwvcD4NCjxwPkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9u Zy10ZXJtICZxdW90O3VzYWdlJnF1b3Q7IGNsYWltICgmcXVvdDt0eXBlJnF1b3Q7IGlzIHRha2Vu KSB0aGF0IHNob3VsZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJDUC48 bzpwPjwvbzpwPjwvcD4NCjxwPkRpZCBJIG1pc3MgYW55dGhpbmc/PG86cD48L286cD48L3A+DQo8 cD5CeSB0aGUgd2F5LCBpZiB3ZSBkbyBhZGQgYSAmcXVvdDt1c2FnZSZxdW90OyBjbGFpbSwgd2Ug bmVlZCB0byBhbHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBpcyBwdWJs aXNoZWQuPG86cD48L286cD48L3A+DQo8cD5UaGFua3MsPG86cD48L286cD48L3A+DQo8cD4mbmJz cDsmbmJzcDsmbmJzcDsgWWFyb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biAxNS8wNi8xNyAyMjowOCwgSnVzdGluIFJpY2hlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MSB0byB0aGlzIGFzIHdlbGwuDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDvi gJQgSnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1 ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0MzsxIHRvIHdoYXQgQW5uYWJlbGxl IHNhaWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2luZyB0aGUgb3RoZXIgcmVxdWlyZW1lbnQsIGZvciBS UHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQLiBUaGUgaXNzJiM0MztzdWIgcGFpciBhdCB0aGUg dG9wIGxldmVsIGlzIGJyb2tlbiBpbiB0aGlzIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWFy aXVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50 QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt XzI4ODgzMTczNjI2NjgyMDY3NDVnbWFpbC1tXzIxMzA3ODM5ODg5NDUyNDY1MzVtXzQ2Mzk3MTg4 OTg2NDc3NDk2NjhtXzQ0NDE3MTQ0NDg3MjEwNzcwNTdtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBs ZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yODg4MzE3MzYyNjY4MjA2NzQ1Z21haWwtbV8yMTMw NzgzOTg4OTQ1MjQ2NTM1bV80NjM5NzE4ODk4NjQ3NzQ5NjY4bV80NDQxNzE0NDQ4NzIxMDc3MDU3 bV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6 b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5NaWtlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91ciBleHBsYW5hdGlv biBmb3Igd2h5IHRoaXMgaXMgYSBub24tcHJvYmxlbSBpcyBkZXBlbmRlbnQgdXBvbiBzaWRlIGVm ZmVjdHMgb2YgZWxlbWVudHMgb2YgT3BlbklEIENvbm5lY3QgdGhhdCB3ZXJlIG5vdCBkZXNpZ25l ZCB0byBzb2x2ZSB0aGlzIGlzc3VlLiBBcyBhIHJlc3VsdCwgSSBzZWUgc2V2ZXJhbA0KIGlzc3Vl cyB3aXRoIGl0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0yODg4MzE3MzYyNjY4MjA2NzQ1 Z21haWwtbTIxMzA3ODM5ODg5NDUyNDY1MzVtNDYzOTcxODg5ODY0Nzc0OTY2OG00NDQxNzE0NDQ4 NzIxMDc3MDU3bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIj4NCjEuPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ DQpUaGUgY2FsbGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0 IGNhbiBiZSBjZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJ RCBUb2tlbi4gQW55IHBhcnR5IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9m ZiB0byBoYXMgbm8gd2F5IHRvIHZlcmlmeSBpdHMgcHJvdmVuYW5jZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtMjg4ODMxNzM2MjY2ODIwNjc0NWdtYWlsLW0yMTMwNzgzOTg4OTQ1MjQ2NTM1 bTQ2Mzk3MTg4OTg2NDc3NDk2NjhtNDQ0MTcxNDQ0ODcyMTA3NzA1N205MDk0MDg5MjM5NjY4NTcw MzEybXNvbGlzdHBhcmFncmFwaCI+DQoyLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KQW55IGZ1dHVyZSBJRCBUb2tlbiBkaXN0 cmlidXRpb24gbWV0aG9kIG5lZWRzIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBhZ2Fpbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtMjg4ODMxNzM2MjY2ODIwNjc0NWdtYWlsLW0yMTMwNzgzOTg4 OTQ1MjQ2NTM1bTQ2Mzk3MTg4OTg2NDc3NDk2NjhtNDQ0MTcxNDQ0ODcyMTA3NzA1N205MDk0MDg5 MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCI+DQozLjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KTm8gb3RoZXIgcHJvZmlsZSBvZiBK V1QgY2FuIGV2ZXIgdXNlIHRoZSAmcXVvdDtub25jZeKAnSBjbGFpbS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtMjg4ODMxNzM2MjY2ODIwNjc0NWdtYWlsLW0yMTMwNzgzOTg4OTQ1MjQ2NTM1 bTQ2Mzk3MTg4OTg2NDc3NDk2NjhtNDQ0MTcxNDQ0ODcyMTA3NzA1N205MDk0MDg5MjM5NjY4NTcw MzEybXNvbGlzdHBhcmFncmFwaCI+DQo0LjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KVGhpcyBpcyBvbmx5IGEgc29sdXRpb24gZm9yIElE IFRva2Vucy4gRXZlcnkgb3RoZXIgSldUIHByb2ZpbGUgdGhhdCBjYXJlcyBhYm91dCBkaXNhbWJp Z3VhdGlvbiBoYXMgdG8gaW52ZW50IGl0cyBvd24gc29sdXRpb24gdG8gdGhlIHByb2JsZW0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBrbm93IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5h bWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNrcyBhcmUgYm90aCB0aGluZ3MgdGhhdCBo YXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlzIGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVh c3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3UgYnJvdWdodA0KIHVwIEpXVCBsaWJyYXJpZXM6 IGEgZ2VuZXJhbCBzb2x1dGlvbiBhY3R1YWxseSBtYWtlcyBpdCBlYXNpZXIgdG8gdXNlIGNvbW1v biBsaWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBBIOKAnHVzYWdlLWF3YXJl4oCdIEpXVCBsaWJy YXJ5IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlvbiBmb3IgYW55IEpXVCBwcm9maWxlLCB3aGVy ZWFzIHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBwcm9maWxlIHdvdWxkIHJlcXVpcmUgdW5pcXVl IGxvZ2ljLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWRlbnRpdHkgU2Vydmlj ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PkZyb206DQo8L2I+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3 IGF0IDE6MTYgUE08YnI+DQo8Yj5UbzogPC9iPk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9 Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1 QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7LCBJRCBFdmVudHMg TWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7LCBIZW5rIEJpcmtob2x6ICZsdDs8 YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJf YmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNv bmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+WW91 4oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4mbmJzcDsgSeKAmWQg Y2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0aHJlYWQgYXMg4oCccHJlbWF0dXJl IHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRoYXQgY2FuIGFuZCBzaG91bGQNCiBi ZSBzaW1wbGUgY29tcGxleCwgd2l0aG91dCBkYXRhIHNob3dpbmcgdGhlcmXigJlzIGFueSBuZWVk IHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1hbmRh dG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGluIHRoaXMgdGhyZWFkIHRvIHByb2Js ZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZl LiZuYnNwOyBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlzaGVkDQogdGhhdCBpdOKAmXMgaW1w b3NzaWJsZSBmb3IgYSBTRVQgdG8gYmUgY29uZnVzZWQgZm9yIGFuIElEIFRva2VuIOKAkyBzZWUg PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbC0yRGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9t c2cwMDQyOC5odG1sJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2Fp MTE1YyZhbXA7cz1lS0xUUVBtWXJWM1RoZkRibjkwU0NzNTVVUk9UUGluX2xnYzZSZHI1WG93JmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4Lmh0bWw8L2E+LiZuYnNwOyBJZiBwZW9wbGUg aGF2ZSBkYXRhIHNob3dpbmcgdGhhdCB0aGlzIGlzIHBvc3NpYmxlIHdpdGggc3BlY2lmaWMga2lu ZHMgb2YgQWNjZXNzIFRva2VucyBvciBvdGhlciByZWFsIEpXVCBkZXBsb3ltZW50cywgcGxlYXNl IHByb3ZpZGUgc3BlY2lmaWNzLCBzbyB0aGF0IHdlIGNhbiB1c2UgdGhhdCBkYXRhIHRvIGluZm9y bQ0KIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNob2ljZXMgb24gb3VyIHBhcnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhlIHByb3Bvc2VkIOKAnHNvbHV0aW9u c+KAnSwgc3VjaCBhcyBwcm9oaWJpdGluZyB0aGUgdXNlIG9mIOKAnHN1YuKAnSBpbiB0aGUgbm9y bWFsIHdheSwgb3IgcmVxdWlyaW5nIGEgdHlwZSBjbGFpbSwgd291bGQgbWFrZSBwcmV2aW91c2x5 IHNpbXBsZSB0aGluZ3MgdW5uZWNlc3NhcmlseQ0KIGNvbXBsZXguJm5ic3A7IFllcywgdGhlbiB0 aGUgcmVzdWx0IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1dCBhIGNvbnNl cXVlbmNlIG9mIHRoaXMgaXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxkIGhhdmUgdG8g YmUgdXNlZCwgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiZuYnNwOyBUaGUgbW9y ZSB1bndpZWxkeSB3ZSBtYWtlIGl0IHRvIHVzZSBTRVRzLCB0aGUgbW9yZSBsaWtlbHkgZGV2ZWxv cGVycyBhcmUgdG8NCiBqdXN0IGNyZWF0ZSB0aGVpciBvd24gZGF0YSBzdHJ1Y3R1cmVzLiZuYnNw OyBLZWVwaW5nIGl0IHNpbXBsZSBpcyB0aGUga2V5IHRvIGFkb3B0aW9uLiZuYnNwOyBTdGFuZGFy ZHMgYXJlIG9ubHkgdXNlZnVsIGlmIHRoZXkgYXJlIGFjdHVhbGx5IHVzZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gSWQtZXZlbnQgWzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEz LCAyMDE3IDU6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhy ZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRl c2N1QGdvb2dsZS5jb208L2E+Jmd0OzsgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5rLmJp cmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElEIEV2ZW50 cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24g YW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5FY2hvaW5nIE1hcml1c+KAmXMgcXVlc3Rpb246IGNhbiB5b3UgZXhwbGFpbiB3 aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3b3VsZCBi ZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJvcGVydHkg dGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBhbmQgdGhhdCBh IHJlY2lwaWVudA0KIG1heSByZWZlciB0byB3aGVuIGRldGVybWluaW5nIHdoZXRoZXIgdG8gYWNj ZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbToNCjwvYj5JZC1l dmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9m IE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5UdWVzZGF5LCBKdW5lIDEzLCAyMDE3IGF0IDExOjA1IEFNPGJyPg0KPGI+VG86 IDwvYj5IZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9m ZXIuZGU8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZl bnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBz b2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlz c3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEp1biAxMywgMjAxNyBhdCAyOjExIEFNLCBIZW5r IEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgYSAybmQgcXVl c3Rpb24uPGJyPg0KPGJyPg0KV2hhdCBzZW1hbnRpY3Mgd291bGQgJnF1b3Q7dXNhZ2UmcXVvdDsg cHJvdmlkZSB0aGF0IHRoYXQgYXJlIG5vdCBjb3ZlcmVkIHZpYSAmcXVvdDtpbnRlbmQmcXVvdDss ICZxdW90O2F1ZGllbmNlJnF1b3Q7LCBhbmQgJnF1b3Q7c2NvcGUmcXVvdDs/PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1 b3Q7YXVkJnF1b3Q7IChhdWRpZW5jZSkgc3BlY2lmaWVzIHRoZSB0YXJnZXQgY2xpZW50LCBidXQg bm90IHRoZSBpbnRlbmRlZCB1c2FnZSAoYWNjZXNzIHRva2VuIHRvIGF1dGhvcml6ZSByZXNvdXJj ZSBhY2Nlc3Mgb3IgU0VUIHRvIGNvbW11bmljYXRlIGEgc2VjdXJpdHkgZXZlbnQ/KTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7 c2NvcGUmcXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb24ndCBrbm93IHdoYXQgZG8geW91 IG1lYW4gYnkgJnF1b3Q7aW50ZW5kJnF1b3Q7IChvciBpbnRlbnQpPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8YnI+DQpIZW5rPGJyPg0KPGJy Pg0KT24gMDYvMTMvMjAxNyAwMTowMSBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciBwdXR0aW5nIHRo aXMgdG9nZXRoZXIhPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQg aW4gMy45IGFyZSBmbGF3ZWQ6PGJyPg0KPGJyPg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0 IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2Yg dmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0aGlz IHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9hY2gg dG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0 YWtlbiBmb3IgSldUcw0KIGZyb20gYSBjdXJyZW50IHNwZWMuPGJyPg0KPGJyPg0KwrdJdCBpcyB1 bnJlYWxpc3RpYyB0byBleHBlY3QgaW1wbGVtZW50ZXJzIHRvIGFkaGVyZSB0byB0aGUg4oCcZGlm ZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1Rz4oCdIHJ1bGUuIFdoZXRoZXIg bWFuZGF0ZWQgYnkgdGhlIHNwZWMgb3Igbm90LCBpbXBsZW1lbnRlcnMgd2lsbCBpZ25vcmUgdGhp cyBiZWNhdXNlIG1hbmFnaW5nIG9uZSBrZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZm ZXJlbnQga2V5cy48YnI+DQo8YnI+DQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KA nSBjbGFpbXMuPGJyPg0KPGJyPg0KJiM0MzsxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2Xi gJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci48YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KPGJyPg0KSWRlbnRpdHkgU2VydmljZXM8YnI+DQo8 YnI+DQoqRnJvbTogKklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE08YnI+DQoqVG86 ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQoq Q2M6ICpBZGFtIERhd2VzICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7LCAmcXVvdDttYXRha2UsIG5v diZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5r Ij5ub3ZAbWF0YWtlLmpwPC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhy ZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGll dGYub3JnPC9hPiZndDssDQogJnF1b3Q7UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KKlN1YmplY3Q6ICpSZTogW0lkLWV2ZW50XSBzb2x1dGlv biBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcjxi cj4NCjxicj4NCkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMgb2YgZGlzY3Vz c2lvbiBvbiB3aGF0IHNob3VsZCBiZSBpbiAzLjkuPGJyPg0KPGJyPg0KT24gTW9uLCBKdW4gMTIs IDIwMTcgYXQgMzoxNSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNv bTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2ZXJ5 IGdvb2QgdGltaW5nIDotKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIGlzc3VlIGlzIGRl c2NyaWJlZCBieSAmcXVvdDsyLjcuIENyb3NzLUpXVCBDb25mdXNpb24mcXVvdDsgYW5kIHRoZTxi cj4NCiZuYnNwOyAmbmJzcDsgbWl0aWdhdGlvbiBpcyBpbiAmcXVvdDszLjkuIFVzZSBNdXR1YWxs eSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3I8YnI+DQombmJzcDsgJm5ic3A7IERpZmZl cmVudCBLaW5kcyBvZiBKV1RzJnF1b3Q7LCBzcGVjaWZpY2FsbHkgJnF1b3Q7VXNlIGRpZmZlcmVu dCBzZXRzIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyByZXF1aXJlZCBjbGFpbXMuLi4mcXVvdDssICZx dW90O1VzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mPGJyPg0KJm5ic3A7 ICZuYnNwOyBKV1RzLiZxdW90OyBhbmQgJnF1b3Q7VXNlIGRpZmZlcmVudCBpc3N1ZXJzIGZvciBk aWZmZXJlbnQga2luZHMgb2YgSldUcy4mcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJ IHN0aWxsIHRoaW5rIHRoYXQgYSAmcXVvdDt0eXBlJnF1b3Q7IGNsYWltIHdvdWxkIGJyaW5nIGEg bG90IG9mIGNsYXJpdHkgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyBzYWZldHkuPGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIFRo dSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5j b208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBZ YXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2VsZi0yRGlzc3VlZC5pbmZvXy0zRnAtM0Qx NjkwJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtL WTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7 cz1hN1h2WjVqVGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTY5MDwvYT48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5 OjAyIFBNIEFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFkYXdlc0Bnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEkgd2Fz IGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMgdG8gYmUgdmVyeSBzaW1pbGFyIHRvPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaWQgdG9rZW5zIGJ1 dCBJIG5vdyB0aGluayB0aGlzIGlzIGEgYmV0dGVyIHBsYW4uPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA2 OjU2IFBNIG1hdGFrZSwgbm92ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFy Z2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bm92QG1hdGFr ZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPm5vdkBtYXRha2UuanA8L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOzEgZXNwZWNpYWxseSBmb3IgJnF1b3Q7dHlwZSZxdW90Ozxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg MjAxNy0wNi0wOSAxMDozMiBHTVQmIzQzOzA5OjAwIFBoaWwgSHVudCAoSURNKTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsm Z3Q7Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOzE8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUGhpbDxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IE9uIEp1biA4 LCAyMDE3LCBhdCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZs dDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdv b2dsZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSB3ZXJlIGEgY291cGxlIG9mIHByb3Bv c2FscyBvbiBob3cgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlzdGluZ3Vpc2ggU0VUcyBmcm9tIElk IFRva2VucyBhbmQgQWNjZXNzIFRva2VucyBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdWNoIGEgd2F5 IHRoYXQgbmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNv bmZ1c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJpdHk8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgdnVsbmVyYWJpbGl0aWVzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCBy ZXF1aXJlbWVudDogdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNl cyBtdXN0IGJlIGRpZmZlcmVudCBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzdWIm cXVvdDsgaXNzdWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcgU0VUczxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB0byBhbiBJZFAuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5k IEkgcHJvcG9zZSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9sbG93aW5nOjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7IC0gYm90aCAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90 OyB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZXZlbDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGF0IGV2ZW50IGxldmVs IGFuZCBhdCB0b3AgU0VUIGxldmVsIGNhbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBkaWZmZXJlbnQ8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O2lzcyZxdW90OyBhbmQgJnF1b3Q7 c3ViJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgYWNyb3NzIGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyAtICZxdW90O3N1YiZxdW90OyBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBT RVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3VhdGlv biksIHBsZWFzZSBub3RlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3Nob3VsZCZxdW90OyBhbmQg bm90ICZxdW90O211c3QmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFRoaXMgc29sdXRpb24gYWxzbyBhbGxvd3MgZGlmZmVyZW50 IHByb2ZpbGVzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGV2ZW50IHR5cGVzIHRvIGRl ZmluZSBhZGRpdGlvbmFsIGNsYWltczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGVkIHRvIHN1YiAo bGlrZSBlbWFpbCBvciBwaG9uZV9udW1iZXIpIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaW5jZSBh bGwgdGhlc2UgY2xhaW1zIHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxldmVsPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHRoZXJlIHdpbGwgYmUgbm8gY29sbGlzaW9ucyBvciBhbWJpZ3VpdHkuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBBbm90aGVyIHBy b3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlZmlu ZSBhIGNvbXBvc2l0ZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmc8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0Jm5ic3A7IFNF VCBpc3N1ZXIuIEFsc28sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGhhdmluZyB0aGUgc2FtZSBjbGFpbSBu YW1lIGhhdmluZyBkaWZmZXJlbnQgc3ludGF4PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIGRpZmZlcmVu dCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFuZCB5ZXQgYW5vdGhlciBw cm9wb3NhbCB3YXMgdG8gaW50cm9kdWNlIGEgbmV3PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNsYWltIGZv ciBKV1RzIHRoYXQgZGVmaW5lcyBhICZxdW90O3R5cGUmcXVvdDsuIFRoaXMgaXMgbm90PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwgYW5kIGl0IGFsc28gaXMg bm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNvbHZpbmcgdGhlIGRpc3RpbmN0IGlzc3VlciByZXF1aXJl bWVudCwgYnV0IEkgdGhpbms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhpcyBpcyBzb21ldGhpbmcgdGhl IEpXVCBncm91cCBzaG91bGQgc2VyaW91c2x5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNpZGVyLjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg VGhvdWdodHM/PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsNCjxh IGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50 QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VH SnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1 YTZtaVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQ UUZKTGh4V0kmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFX Z2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0km YW1wO2U9PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VH SnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0 LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3 VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQt ZXZlbnRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdK UEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklU WDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSA8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBZGFtIERhd2VzIHwgU3IuIFBy b2R1Y3QgTWFuYWdlciB8PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YWRhd2VzQGdvb2dsZS5jb208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHw8YSBo cmVmPSJ0ZWw6JTJCMSUyMDY1MC0yMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7MSA2NTAt MjE0LTI0MTA8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0OzxhIGhyZWY9InRlbDolMjg2NTAlMjklMjAyMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsi PnRlbDooNjUwKSUyMDIxNC0yNDEwPC9hPiZndDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3Jn PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FR JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9 SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dV N0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllW SVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSA8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgJmx0OzxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUu Y29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1w O3M9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vaGFyZHR3YXJlLmNvbS88L2E+Jmd0Ow0KIG1haWwgbGlzdCB0 bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFybiBhYm91dCBwcm9qZWN0cyBJ IGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KPGJyPg0KU3Vi c2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01H YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9aTc1VXc4YWVoWXZs cElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vaGFyZHR3YXJlLmNvbS88L2E+Jmd0Ow0KIG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBw cm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VH SnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0 LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3 VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBF aXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZ XzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdN U1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0 NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1 eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZ UjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBF aXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZ XzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdN U1dXcyZhbXA7ZT08L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklkLWV2ZW50IG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_CY4PR21MB05049568082B6C260AFDE06AF5DA0CY4PR21MB0504namp_-- From nobody Wed Jun 21 15:32:40 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6660B128B37 for ; Wed, 21 Jun 2017 15:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbiLIL7UlYhl for ; Wed, 21 Jun 2017 15:32:34 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72E0127137 for ; Wed, 21 Jun 2017 15:32:33 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m47so40615317iti.1 for ; Wed, 21 Jun 2017 15:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=atUSrwscD1oJvkjHshVpG0aF0epWPbobC7wmHZGvZXY=; b=CpTJ6xwy3M5LzYICoCaEaq8hWmKdsRsmzAOVoMtOAEg14OxEC22Pll2tyN73h85LYT NWTIgQTUOtzuZRs50F+jtgO3AvJQuLZdMOjWILUT8t8TmwOojD+t2QikgbzGLALUcnR5 68/yb489XQ5xJVUym8GtvKNVbDdH6462EnaALAkVlKm3DtpsUHpyzUZVAy0hbsebGmyR p2hy1daIl+GGR6cZGcPcZmr1dHo7uTKbHcn6jk6xRM/O9tJ/ohbCNeVI5vK8ncnbg8JV tgMeG7i+O6NUYS5YclHoyi4wZxiBhzJYg7HlPhbDDDNKA3s4nXQ9fF0c2dtvuEir2lxP XxMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=atUSrwscD1oJvkjHshVpG0aF0epWPbobC7wmHZGvZXY=; b=p9rRUWigcIF5HbYS77xffDZrzQWckbDMQY7XowhYnpkwRLktYqXyQzB0xyL4NvQ96B Tgr0zmM3MX7Kl/3KCyUPb+PjYIxPTPn9L6Uqx1NzC/1TJMz/qBhHvsgRNVbxn4nAdlL+ XpDo7mhk4QZJTB53VZfHGSfrtzaWK4/A5+3/i7rmzxeAruPjvYaaZby0q5hWIBORFMGZ E0F42OsBuCLuY+So9T2/slWX5ZDGr9bJSrX4puYgnLUxKnd8C6fPPinJTbyFXNhRbPOS jo3Nd6gOvHswDuCCP2GvawfpzN8p3eCJB7LIJFxhDGKn59/gx6ww0Fmo0okAR5rvSxsD Zegg== X-Gm-Message-State: AKS2vOzfjuWP3Ijj29fynyEK8eqX1m557xQnnMr275iQVY0MW4Ax/9LE IAO0aAZ9dYcsUbfIgAWUbvkqjaOqdJs9 X-Received: by 10.36.217.207 with SMTP id p198mr11667865itg.116.1498084352425; Wed, 21 Jun 2017 15:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Wed, 21 Jun 2017 15:32:11 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <6AC4267E-287D-470D-9762-E00C56CB0C39@mit.edu> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> From: Marius Scurtescu Date: Wed, 21 Jun 2017 15:32:11 -0700 Message-ID: To: Mike Jones Cc: "M.Lizar@OCG" , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="001a113718b2ac06f205527ff178" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:32:38 -0000 --001a113718b2ac06f205527ff178 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2017 at 3:03 PM, Mike Jones wrote: > Marius, you wrote =E2=80=9CBTW, you never offered a solution to the RP is= sued > SETs problem MIke. Can you please do that?=E2=80=9D I thought we already= had a > well-understood solution to that, but I=E2=80=99ll repeat it here. I=E2= =80=99ll give the > example assuming that the event is about an OpenID Connect account that i= s > named by an (=E2=80=9Ciss=E2=80=9D, =E2=80=9Csub=E2=80=9D) pair. > > > > If the RP is issuing the SET, it already must identify itself using the > top-level =E2=80=9Ciss=E2=80=9D claim, per the SET spec. The OpenID Conn= ect account that > is the subject of the event would contain the (=E2=80=9Ciss=E2=80=9D, =E2= =80=9Csub=E2=80=9D) values in the > event payload. In fact, I=E2=80=99m assuming that that would be the case= for all > RISC events (and possibly for some other event profiles too). I=E2=80=99= m > completely supportive of that choice if made by a profile. > > > > But there will also be use cases =E2=80=93 possibly non-identity use case= s, in > which the thing being operated on doesn=E2=80=99t have any issuer value o= r in which > the event issuer is always the same as the issuer for the thing being > operated on. Trying to impose the choices made by one SET profile onto a= ll > others, though, assumes we know way more about their use cases than we > actually do. We need to leave their conventions up to them =E2=80=93 jus= t like JWT > left claims conventions up to profiles. That=E2=80=99s why it=E2=80=99s = general-purpose > and being widely used. > Alright, so the solution is to optionally allow iss+sub at the event level (in which case there is no sub at the top level)? Is this something secevent defines or profiles would have to each define separately? And again, I don't see the RP issued SET as a particular profile problem. Also, speaking of general purpose solutions. To me sub at event level is general purpose, guaranteed to not cause conflicts. sub at the top level on the other hand will cause conflicts and force most (or all) oauth based profiles to re-define how sub is used. The only problem with sub only at event level that I am aware of is the compatibly breakage for the logout profile. I agree that we should not take breakages lightly. > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Wednesday, June 21, 2017 4:20 PM > *To:* Mike Jones > *Cc:* M.Lizar@OCG ; Richard Backman, > Annabelle ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>; Justin Richer ; Yaron > Sheffer ; ID Events Mailing List ; > Phil Hunt > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Wed, Jun 21, 2017 at 1:19 PM, Mike Jones > wrote: > > Marius, the question =E2=80=9CDo you have examples of use cases that cann= ot > handle sub at the event level?=E2=80=9D is no more useful than the questi= on =E2=80=9CDo > you have examples of use cases that cannot handle =E2=80=98sub=E2=80=99 s= pelled as the > Latin word =E2=80=98subiectum=E2=80=99?=E2=80=9D > > > > I disagree. If sub at the event level is an issue then let's be concrete > about it. > > > > > > Yes, applications could always work around the inconveniences introduce= d > by arbitrary claim renaming or repositioning, > > > > This is not an arbitrary repositioning, the reasons a very clear. > > > > > > but they shouldn=E2=80=99t have to. It just adds complexity and will hin= der > adoption. > > > > Minor complexity added, if at all. The only downside is the slightly > larger size of SETs. > > > > > > It seems to me that your motivation for always having =E2=80=9Csub=E2=80= =9D in the event > payload, rather than a normal claim, is that that=E2=80=99s how you think= RISC > events will be structured, and that you want **all** events to also use > the RISC event structuring. > > > > This has absolutely nothing to do with RISC in particular. Both the > confusion problem and the RP issued SETs are generic SET problems that ne= ed > to be solved. > > > > BTW, you never offered a solution to the RP issued SETs problem MIke. Can > you please do that? > > > > > > To my way of thinking, if you really believe that you should be asking > the SET spec to be withdrawn from the IETF and only define RISC events in > the RISC working group. But in fact, requiring all events to follow the > RISC conventions makes no more sense than requiring all JWTs to be ID > Tokens. That would have made JWTs useless for many use cases. Proposing > to limit claims usage in SETs would likewise make them inapplicable for > many non-RISC use cases. > > > > We have a potential success on our hands. Let=E2=80=99s not screw it up = by making > it unnecessarily complicated. > > > > Sure, let's solve all open issues first. > > > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Wednesday, June 21, 2017 1:53 PM > *To:* M.Lizar@OCG > *Cc:* Mike Jones ; Richard Backman, > Annabelle ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>; Justin Richer ; Yaron > Sheffer ; ID Events Mailing List ; > Phil Hunt > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG < > m.lizar@openconsentgroup.com> wrote: > > FWIW - I agree with Mike that putting restrictions on the "sub" claim > usage would unnecessarily complicate SETs for some use cases. > > > > sub is defined as optional in JWT, so technically we are not adding any > restrictions. Do you have examples of use cases that cannot handle sub at > the event level? > > > > > > > > Its a lot easier to add to a spec and very difficult (if not impossible) > to retract. > > > > I agree. I don't think anything is retracted. > > > > Again, see: > > https://tools.ietf.org/html/rfc7519#section-4.1.2 > > > > Last sentence of 4.1.2 states "Use of this claim is OPTIONAL." > > > > > > In this regard, keeping it simple is critical for broad adoption. > > > > Mark > > > > On 19 Jun 2017, at 16:55, Marius Scurtescu wrote: > > > > Mike, are you suggesting we define SETs in such a way that they will not > work for RISC? A top level iss+sub is clearly not working for RISC, and m= ay > not work for logout either if you allow logout to be initiated from an RP= . > > > Marius > > > > On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones > wrote: > > Marius, there=E2=80=99s nothing stopping you (or the RISC working group o= r other > profiles) from defining events that can be sent from RPs to IdPs now, > without any changes to the SET spec. Specify the claims you want to use, > and you=E2=80=99re golden. > > > > But it would be counterproductive to require all other SETs to meet the > requirements of your specific profile. There are simpler use cases that > can use claims in simpler ways. Trying to make the simple use cases be > complex will have the side effect of limiting the adoption of the spec, > which wouldn=E2=80=99t be good for anyone. > > > > If successful, SETs will have many different profiles. That=E2=80=99s a = sign of > success =E2=80=93 not a sign of weakness. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Monday, June 19, 2017 11:58 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer ; Justin Richer < > jricher@mit.edu>; Richard Backman, Annabelle ; Henk > Birkholz ; ID Events Mailing List < > id-event@ietf.org>; Phil Hunt > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > > > On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones > wrote: > > I=E2=80=99m sorry to be slow replying to some messages in this thread. I= have a > lot of other things on my plate, but I will take the time now to reply, > because I wholeheartedly disagree with some of the statements below and > believe it would be severely harmful to the specification and its adoptio= n > to act upon them. Specifically: > > > > - I disagree that specific rules should be made for the =E2=80=9Csub= =E2=80=9D claim. > Claims usage needs to be up to the application. I know that many othe= rs > agree with me, because the OpenID Connect working group designed the l= ogout > token in http://openid.net/specs/openid-connect-backchannel-1_ > 0-04.html#LogoutToken (which is also used as an example in > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 > ) > to use the =E2=80=9Csub=E2=80=9D claim in the normal way. Prohibiting= this usage would be > a completely unnecessary breaking change =E2=80=93 as it=E2=80=99s imp= ossible to confuse a > logout token with an ID Token, for reasons already cites in this threa= d. > > Solving the confusion is one problem. The other problem I keep mentioning > is SETs issued by an RP to be sent to an IdP. How are we solving that > problem Mike? In this case the top level iss is different from the iss of > the sub, a top level sub is not possible. > > > > And I don't want to downplay the confusion problem either. I think it is = a > real concern and I think a solid solution is important. > > > > The OpenID Working Group designed logout tokens without secevent in mind. > I agree we should not recklessly break compatibility, but to me it seems > necessary in this case. > > > > > - > > > > - (I agree with the =E2=80=9Ciss=E2=80=9D rules already in place at > https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 > = . > No further =E2=80=9Ciss=E2=80=9D rules are needed.) > > > > Further iss ruies are absolutely needed for the RP to IdP case described > above. > > > > > > > - > > > > - It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to = be used for some > profiles to differentiate between kinds of JWTs. Its use should not b= e > mandated in the SET spec. I would oppose duplicating the =E2=80=9Ctyp= =E2=80=9D > functionality by defining another claim with a duplicative meaning. > > If typ can be use and no other claim is needed, then let's talk about > that. I do think SET should mandate it. I don't understand why not. Can y= ou > please propose with examples how can typ be used? > > > > > > > - > > > > - I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2= =80=9CNo other profile of > JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D This reflects a = misunderstanding. > It=E2=80=99s the **value** of the nonce that self-secures the JWT =E2= =80=93 not that > any =E2=80=9Cnonce=E2=80=9D claim is present. Any and all JWTs can si= multaneously use > =E2=80=9Cnonce=E2=80=9D without any risk of conflict, since the nonce = value is a > cryptographically secure random number. > > > > For SETs I cannot see how the nonce value is useful. That value is not > passed back and it cannot be verified. Only the presence of the claim cou= ld > have some use, hinting at the usage of the JWT, a very weak solution to t= he > confusion problem. > > > > > - > > > > Will some of you be at the Cloud Identity Summit next week? I=E2=80=99d = be glad > to have in-person discussions about these topics there. > > > > -- Mike > > > > P.S. Food for thought: Prohibiting the use of =E2=80=9Csub=E2=80=9D (or= any other claim) > or forcing it to be located in a non-standard location makes about as muc= h > sense as arbitrarily saying that, for a particular profile, the Latin wor= d > for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name in= stead of =E2=80=9Csub=E2=80=9D. > Yes, it will completely differentiate this profile from others not spelli= ng > the claim name this way, but it would certainly be an impediment to the u= se > of standard JWT libraries and to interoperability. > > > > If we define that sub must be at the event level then it is at a standard > location, I don't see what the issue is. The impediment you mention is th= e > actual solution. I don't think that a JWT library that was written for Id > Tokens should be used to parse SETs. The library has to be SET aware, in > which case the event level iss+sub is not an issue at all. > > > > > > > > > > *From:* Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > *Sent:* Saturday, June 17, 2017 1:45 PM > *To:* Justin Richer ; Marius Scurtescu < > mscurtescu@google.com> > *Cc:* Richard Backman, Annabelle ; Mike Jones < > Michael.Jones@microsoft.com>; Henk Birkholz de>; ID Events Mailing List ; Phil Hunt < > phil.hunt@oracle.com> > > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint. > com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id- > 2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > --001a113718b2ac06f205527ff178 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 3:03 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Marius, you wrote =E2= =80=9CBTW, you never offered a solution to the RP issued SETs proble= m MIke. Can you please do that?=E2=80=9D=C2= =A0 I thought we already had a well-understood solution to that, but I=E2=80=99ll repeat it here.=C2=A0 I=E2=80=99ll give the example assum= ing that the event is about an OpenID Connect account that is named by an (= =E2=80=9Ciss=E2=80=9D, =E2=80=9Csub=E2=80=9D) pair.

=C2=A0

If the RP is issuing t= he SET, it already must identify itself using the top-level =E2=80=9Ciss=E2= =80=9D claim, per the SET spec.=C2=A0 The OpenID Connect account that is th= e subject of the event would contain the (=E2=80=9Ciss=E2=80=9D, =E2=80=9Cs= ub=E2=80=9D) values in the event payload.=C2=A0 In fact, I=E2=80=99m assuming that that would = be the case for all RISC events (and possibly for some other event profiles= too).=C2=A0 I=E2=80=99m completely supportive of that choice if made by a = profile.

=C2=A0

But there will also be= use cases =E2=80=93 possibly non-identity use cases, in which the thing be= ing operated on doesn=E2=80=99t have any issuer value or in which the event= issuer is always the same as the issuer for the thing being operated on.=C2=A0 Trying to impose the choices made by one SET prof= ile onto all others, though, assumes we know way more about their use cases= than we actually do.=C2=A0 We need to leave their conventions up to them = =E2=80=93 just like JWT left claims conventions up to profiles.=C2=A0 That=E2=80=99s why it=E2=80=99s general-purpose and bei= ng widely used.


Alri= ght, so the solution is to optionally allow iss+sub at the event level (in = which case there is no sub at the top level)? Is this something secevent de= fines or profiles would have to each define separately?

And again, I don't see the RP issued SET as a particular profile = problem.

Also, speaking of general purpose solutio= ns. To me sub at event level is general purpose, guaranteed to not cause co= nflicts. sub at the top level on the other hand will cause conflicts and fo= rce most (or all) oauth based profiles to re-define how sub is used.

The only problem with sub only at event level that I= am aware of is the compatibly breakage for the logout profile. I agree tha= t we should not take breakages lightly.

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mail= to:mscurtescu@google.com]
Sent: Wednesday, June 21, 2017 4:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: M.Lizar@OCG <m.lizar@openconsentgroup.com>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz= <henk.birkholz@sit.fraunhofer.de>; Justin Richer= <= jricher@mit.edu>; Yaron Sheffer <yaronf.ietf@gmail.com>; = ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Wed, Jun 21, 2017 at 1:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Marius, the question = =E2=80=9CDo you have examples of use cases that cannot handle sub at= the event level?=E2=80=9D is no more useful than the question =E2=80=9CDo you have examples of use cases that cannot h= andle =E2=80=98sub=E2=80=99 spelled as the Latin word =E2=80=98subiectum=E2= =80=99?=E2=80=9D

=C2=A0

I disagree. If sub at the event level is an issue th= en let's be concrete about it.

=C2=A0

=C2=A0

=C2=A0 Yes, applicatio= ns could always work around the inconveniences introduced by arbitrary clai= m renaming or repositioning,

=C2=A0

This is not an arbitrary repositioning, the reasons = a very clear.

=C2=A0

=C2=A0

but they shouldn=E2=80= =99t have to.=C2=A0 It just adds complexity and will hinder adoption.

=C2=A0

Minor complexity added, if at all. The only downside= is the slightly larger size of SETs.

=C2=A0

=C2=A0

It seems to me that yo= ur motivation for always having =E2=80=9Csub=E2=80=9D in the event payload,= rather than a normal claim, is that that=E2=80=99s how you think RISC even= ts will be structured, and that you want *all* events to also use the = RISC event structuring.

=C2=A0

This has absolutely nothing to do with RISC in parti= cular. Both the confusion problem and the RP issued SETs are generic SET pr= oblems that need to be solved.

=C2=A0

BTW, you never offered a solution to the RP issued S= ETs problem MIke. Can you please do that?

=C2=A0

=C2=A0

=C2=A0 To my way of th= inking, if you really believe that you should be asking the SET spec to be = withdrawn from the IETF and only define RISC events in the RISC working group.=C2=A0 But in fact, requiring all events to follow the = RISC conventions makes no more sense than requiring all JWTs to be ID Token= s.=C2=A0 That would have made JWTs useless for many use cases.=C2=A0 Propos= ing to limit claims usage in SETs would likewise make them inapplicable for many non-RISC use cases.

=C2=A0

We have a potential su= ccess on our hands.=C2=A0 Let=E2=80=99s not screw it up by making it unnece= ssarily complicated.

=C2=A0

Sure, let's solve all open issues first.<= u>

=C2=A0

=C2=A0

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

=C2=A0

From: Marius Scurtescu [mailto:mscurtescu@go= ogle.com]
Sent: Wednesday, June 21, 2017 1:53 PM
To: M.Lizar@OCG <m.lizar@openconsentgroup.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Richa= rd Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Justin Richer <jricher@mit.edu>; Yaron Sheffer <yaronf.ietf@gmail= .com>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hunt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@O= CG <m.lizar@openconsentgroup.com> wrote:

FWIW - I agree with Mike that pu= tting restrictions on the "sub" claim usage would unnecessarily complicate SETs for some use cases.

=C2=A0

sub is defined as optional in JWT, so technically we= are not adding any restrictions. Do you have examples of use cases that ca= nnot handle sub at the event level?

=C2=A0

=C2=A0

=C2=A0

It= s a lot easier to add to a spec and very=C2=A0difficult=C2=A0(if not imposs= ible) to retract.

=C2=A0

I agree. I don't think anything is retracted.=

=C2=A0

Again, see:

=C2=A0

Last sentence of 4.1.2 states "Use of this clai= m is OPTIONAL."

=C2=A0

=C2=A0

In= this regard, keeping it simple is critical for broad adoption.=C2=A0

=C2=A0

Ma= rk

=C2=A0

On 19 Jun 2017, at 16:55, Marius Scurtescu <mscu= rtescu@google.com> wrote:

=C2=A0

Mike, are you suggesting we define SETs in such a wa= y that they will not work for RISC? A top level iss+sub is clearly not work= ing for RISC, and may not work for logout either if you allow logout to be initiated from an RP.


Marius

=C2=A0

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Marius, there=E2=80=99= s nothing stopping you (or the RISC working group or other profiles) from d= efining events that can be sent from RPs to IdPs now, without any changes to the SET spec.=C2=A0 Specify the claims you want to use, and= you=E2=80=99re golden.

=C2=A0

But it would be counte= rproductive to require all other SETs to meet the requirements of your spec= ific profile.=C2=A0 There are simpler use cases that can use claims in simpler ways.=C2=A0 Trying to make the simple use cases be c= omplex will have the side effect of limiting the adoption of the spec, whic= h wouldn=E2=80=99t be good for anyone.

=C2=A0

If successful, SETs wi= ll have many different profiles.=C2=A0 That=E2=80=99s a sign of success =E2= =80=93 not a sign of weakness.

=C2=A0

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

=C2= =A0

From: Marius Scurtescu [mailto:mscurtescu@go= ogle.com]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Justin Richer = <j= richer@mit.edu>; Richard Backman, Annabelle <richanna@amazon.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>;= ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hu= nt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

=C2=A0

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m sorry to b= e slow replying to some messages in this thread.=C2=A0 I have a lot of othe= r things on my plate, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it= would be severely harmful to the specification and its adoption to act upo= n them.=C2=A0 Specifically:

=C2=A0

Solving the confusion is one problem. The other prob= lem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are= we solving that problem Mike? In this case the top level iss is different from the iss of the sub, a top level sub is not pos= sible.

=C2=A0

And I don't want to downplay the confusion probl= em either. I think it is a real concern and I think a solid solution is imp= ortant.

=C2=A0

The OpenID Working Group designed logout tokens with= out secevent in mind. I agree we should not recklessly break compatibility,= but to me it seems necessary in this case.

=C2=A0

  • =C2=A0

=C2=A0

=C2=A0

Further iss ruies are absolutely needed for the RP t= o IdP case described above.

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

  • It=E2=80=99s fine for the =E2=80=9Ctyp=E2=80=9D header parameter to be used= for some profiles to differentiate between kinds of JWTs.=C2=A0 Its use sh= ould not be mandated in the SET spec.=C2=A0 I would oppose duplicating the = =E2=80=9Ctyp=E2=80=9D functionality by defining another claim with a duplic= ative meaning.

If typ can be use and no other claim is needed, then= let's talk about that. I do think SET should mandate it. I don't u= nderstand why not. Can you please propose with examples how can typ be used?

=C2=A0

=C2=A0

  • =C2=A0

=C2=A0

  • I=E2=80=99ll also respond to Annabelle=E2=80=99s assertion that =E2=80=9CNo= other profile of JWT can ever use the "nonce=E2=80=9D claim.=E2=80=9D= =C2=A0 This reflects a misunderstanding.=C2=A0 It=E2=80=99s the *value* of the nonce that self-secures the JWT =E2=80=93 not that any =E2=80=9C= nonce=E2=80=9D claim is present.=C2=A0 Any and all JWTs can simultaneously use =E2=80=9Cnonce=E2=80=9D without any risk of co= nflict, since the nonce value is a cryptographically secure random number.<= u>

=C2=A0

For SETs I cannot see how the nonce value is useful.= That value is not passed back and it cannot be verified. Only the presence= of the claim could have some use, hinting at the usage of the JWT, a very weak solution to the confusion problem.=

=C2=A0

  • =C2=A0

=C2=A0

Will some of you be at= the Cloud Identity Summit next week?=C2=A0 I=E2=80=99d be glad to have in-= person discussions about these topics there.

=C2=A0

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

=C2=A0

P.S.=C2=A0 Food for th= ought:=C2=A0 Prohibiting the use of =E2=80=9Csub=E2=80=9D (or any other cla= im) or forcing it to be located in a non-standard location makes about as m= uch sense as arbitrarily saying that, for a particular profile, the Latin word= for subject =E2=80=9Csubiectum=E2=80=9D must be used as the claim name ins= tead of =E2=80=9Csub=E2=80=9D.=C2=A0 Yes, it will completely differentiate = this profile from others not spelling the claim name this way, but it would certainly be an impediment to the use of standard JWT libraries and = to interoperability.

=C2=A0

If we define that sub must be at the event level the= n it is at a standard location, I don't see what the issue is. The impe= diment you mention is the actual solution. I don't think that a JWT library that was written for Id Tokens should be used to parse = SETs. The library has to be SET aware, in which case the event level iss+su= b is not an issue at all.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Yaron Sheffer [mailto:yaronf.ietf@gmai= l.com]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <jricher@mit.edu>; Marius Scurtescu <mscu= rtescu@google.com>
Cc: Richard Backman, Annabelle <richanna@amazon.com>; Mike = Jones <Michael.Jones@microsoft.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; ID Events Mailing List <id-event@ietf.org>; Phil Hunt <phil.hu= nt@oracle.com>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules f= or "sub" and "iss" that can be defined in the SET spec.=

Almost everybody agrees on a long-term "usage" claim ("ty= pe" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use = it in the SET document before it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 15/06/17 22:08, Justin Richer wrote:

+1 to this as well.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <m= scurtescu@google.com> wrote:

=C2=A0

+1 to what Annabelle said.

=C2=A0

Also, Mike you are missing the other requirement, fo= r RPs to send events to an IdP. The iss+sub pair at the top level is broken= in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <= ;phil.hunt@oracle.com> wrote:

+1

=C2=A0

Phil


On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.= com> wrote:

Mike,

=C2=A0

Your explanation for why this is a non-problem is de= pendent upon side effects of elements of OpenID Connect that were not desig= ned to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The caller of the Token Endpoint is the only party that can be certain that= a nonce-less ID Token is really an ID Token. Any party that the caller pas= ses the ID Token off to has no way to verify its provenance.<= /p>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any future ID Token distribution method needs to solve this problem again.<= u>

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No other profile of JWT can ever use the "nonce=E2=80=9D claim.=

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is only a solution for ID Tokens. Every other JWT profile that cares a= bout disambiguation has to invent its own solution to the problem.

=C2=A0

We know from experience that naming collisions and r= eplay attacks are both things that happen. What=E2=80=99s being proposed is= a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use commo= n libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library co= uld handle disambiguation for any JWT profile, whereas with the status quo = each profile would require unique logic.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike J= ones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <= ;henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

You=E2=80=99ve heard o= f =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d characterize = the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2= =80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.=

=C2=A0

Mandatory solutions ar= e being proposed in this thread to problems that there=E2=80=99s no evidenc= e that we actually even have.=C2=A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.h= tml.=C2=A0 If people have data showing that this is possible with speci= fic kinds of Access Tokens or other real JWT deployments, please provide sp= ecifics, so that we can use that data to inform appropriate engineering choices on our part.

=C2=A0

The proposed =E2=80=9C= solutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80=9D in= the normal way, or requiring a type claim, would make previously simple th= ings unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT bu= t a consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to us= e SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key = to adoption.=C2=A0 Standards are only useful if they are actually used.

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-bounces@= ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkho= lz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s question: can you explain w= hat you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first question, I think a better analogy wou= ld be the X.509 Key Usage extension: a multi-valued property that declares = the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to i= t in some context.

=C2=A0

--=C2=A0

Annabelle Richard Backman

Identity Services

=C2=A0

=C2=A0

From: Id-event <id-event-bounces@ietf.org> on behalf of Marius= Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.d= e>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <<= a href=3D"mailto:henk.birkholz@sit.fraunhofer.de" target=3D"_blank" class= =3D"cremed">henk.birkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audience) specifies the target clie= nt, but not the intended usage (access token to authorize resource access o= r SET to communicate a security event?)

=C2=A0

"scope" is not used by SET.<= /p>

=C2=A0

I don't know what do you mean by "intend&qu= ot; (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Di= ck Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matak= e.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.co= m <mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gma= il.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" class=3D"cremed">adaw= es@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>> wro= te:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracl= e.com <mailto:phil.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <mailto:mscurtescu@google.com>> wrote:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Id-= event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxP= EivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6mi= RiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&a= mp;e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event= @ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org = <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |ad= awes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>= |+1= 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-eve= nt@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>

=C2=A0

=C2=A0<= /p> 

_______________________________________________

Id-event mailing list


Id-event@ietf.org


https://www.ietf.org/mailman/listinfo/id-event=

=C2=A0

=C2=A0

=C2=A0

_______________________________________________=
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<= u>

=C2=A0

=C2=A0

=C2=A0


--001a113718b2ac06f205527ff178-- From nobody Wed Jun 21 15:38:18 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C525B127137 for ; Wed, 21 Jun 2017 15:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.831 X-Spam-Level: X-Spam-Status: No, score=-9.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBtZl-dvPgxm for ; Wed, 21 Jun 2017 15:38:11 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6A5128B37 for ; Wed, 21 Jun 2017 15:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1498084691; x=1529620691; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pgLDmIdDQuSkeEGSv0UxW7AFl5U/bveueYJ6sxxxzuc=; b=DuenuSfdQqA4EcWg0mwkuYKQomETbW8WRjEzpVhcGRWHV0IK8mC6pnr4 fomwMMqI8EfBoZyQazB7YfYd7TC10nYaxahMtXv8BwfHIH9RZl4wYPtpi j7n3vZsc3j7w5Fg1InAyyaLmQk/yq7j1Ar/9hqTLfsN7lEfv6tX+sVpRc 4=; X-IronPort-AV: E=Sophos;i="5.39,370,1493683200"; d="scan'208,217";a="675884603" Received: from sea19-co-svc-lb5-vlan3.sea.amazon.com (HELO email-inbound-relay-62007.pdx2.amazon.com) ([10.47.22.166]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 22:38:10 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-62007.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP id v5LMc4nb012969 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2017 22:38:07 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Jun 2017 22:38:06 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 21 Jun 2017 22:38:06 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1104.000; Wed, 21 Jun 2017 22:38:06 +0000 From: "Richard Backman, Annabelle" To: Marius Scurtescu CC: "Phil Hunt (IDM)" , John Bradley , Henk Birkholz , "Justin Richer" , Yaron Sheffer , "Michael Jones" , ID Events Mailing List Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9LvfopeZFDkirzZrO/XTOmqIbvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegP//lqwAgAEftACAAJUjgP//9x6AgAG/8QD//9AlgAAO8LsAACLOTQAABCSqAABn9XkAAMj4pQD//468gIAAdqeAgAAD8ID//5ZlAIAAdnWA//+VmYA= Date: Wed, 21 Jun 2017 22:38:05 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.145] Content-Type: multipart/alternative; boundary="_000_E967B191C08B4C96927E8A22E0673AF9amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:38:17 -0000 --_000_E967B191C08B4C96927E8A22E0673AF9amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBwb2ludC4gSWYgd2UgZG8gbm90IGludGVuZCB0byBzdXBwb3J0IG11bHRpcGxlIHByb2Zp bGVzIHdpdGhpbiBhIHNpbmdsZSBTRVQsIHRoZW4gSeKAmW0gbGVzcyBjb25jZXJuZWQgYWJvdXQg bGVhdmluZyBzdWIgc2VtYW50aWNzIHVwIHRvIHRoZSBwcm9maWxlcy4NCg0KLS0NCkFubmFiZWxs ZSBSaWNoYXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogTWFyaXVzIFNj dXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDIx LCAyMDE3IGF0IDI6NTggUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNo YW5uYUBhbWF6b24uY29tPg0KQ2M6ICJQaGlsIEh1bnQgKElETSkiIDxwaGlsLmh1bnRAb3JhY2xl LmNvbT4sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+LCBIZW5rIEJpcmtob2x6IDxo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PiwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPiwgTWljaGFlbCBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiwgSUQgRXZlbnRzIE1haWxpbmcgTGlz dCA8aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBm b3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpF eGFtcGxlIGZvciBtdWx0aXBsZSBldmVudHMgd2l0aGluIHNhbWUgcHJvZmlsZTogSWRQIGFjY291 bnQgaXMgZGlzYWJsZWQgKGJlY2F1c2Ugb2YgaGlqYWNraW5nKSwgdGhpcyBjYW4gbGVhZCB0byB0 d28gZXZlbnRzOg0KMS4gImFjY291bnQtZGlzYWJsZWQiDQoyLiAic2Vzc2lvbnMtcmV2b2tlZCIN Cg0KTWFyaXVzDQoNCk9uIFdlZCwgSnVuIDIxLCAyMDE3IGF0IDI6NTQgUE0sIFJpY2hhcmQgQmFj a21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6 b24uY29tPj4gd3JvdGU6DQpUaGUgc3BlYyBzYXlzIHRoYXQgdGhlIGV2ZW50cyBjbGFpbSBTSE9V TEQgTk9UIGJlIHVzZWQgdG8gZXhwcmVzcyBtdWx0aXBsZSBsb2dpY2FsIGV2ZW50cy4gSWYgaXTi gJlzIGFsc28gbm90IHVzZWQgdG8gZXhwcmVzcyBldmVudHMgZnJvbSBkaWZmZXJlbnQgcHJvZmls ZXMgdGhhdCBjb3JyZXNwb25kIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGUuZy4gYW4gT0lE QyBiYWNrY2hhbm5lbCBsb2dvdXQgZXZlbnQgYWxvbmdzaWRlIGEgaHlwb3RoZXRpY2FsIFJJU0Mg bG9nb3V0IGV2ZW50KSwgdGhlbiBJ4oCZbSBub3Qgc3VyZSB3aGF0IHVzZSBjYXNlIHRoYXQgbGVh dmVzIGZvciBtdWx0aXBsZSBldmVudHMgaW4gb25lIFNFVC4NCg0KLS0NCkFubmFiZWxsZSBSaWNo YXJkIEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2 ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBv biBiZWhhbGYgb2YgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcg YXQgMjoxMiBQTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tPj4NCkNjOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNo YW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIEhlbmsgQmlya2hv bHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGU+PiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0 bzpqcmljaGVyQG1pdC5lZHU+PiwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiwgWWFyb24gU2hlZmZlciA8eWFyb25m LmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiwgTWljaGFlbCBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20+PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29s dXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1 ZXINCg0KU2VwYXJhdGUgb3IgY29tYmluZWQgbWF5IGJlIGV2b2x2aW5nLiBNaWtlIHdhbnRzIHRv IGtlZXAgdGhlIGN1cnJlbnQgYmFja2NoYW5uZWwgbG9nb3V0IHZlcnkgbmFycm93bHkgc2NvcGVk LiBIZSBzdWdnZXN0ZWQgcmlzYyBkZWZpbmUgaXRzIG93biBkdXBsaWNhdGUgZGVmaW5pdGlvbnMg YW5kIG1lYW5pbmdzLg0KDQpUaGF0IGxlYWRzIG1lIHRvIGJlbGlldmUgd2Ugd2lsbCBoYXZlIG11 bHRpLXR5cGUgZXZlbnRzIGluIHByYWN0aWNlLg0KDQpTZXNzaW9uIGNhbmNlbGxhdGlvbiBjYW4g b2NjdXIgZm9yIG1hbnkgcmVhc29ucy4gT25lIG9mIHRoZSBkaWZmZXJlbnRpYXRvcnMgd2UgaGFk IHRyaWVkIHRvIG1ha2Ugd2FzIGFuIGFzc3VtcHRpb24gdGhhdCB1c2VyIGluaXRpYXRlZCBldmVu dHMgd291bGQgYmUgcGFydCBvZiBjb25uZWN0LiBSaXNrIHdvdWxkIGNvdmVyIHZhcmlhdGlvbnMg dGhhdCBkcml2ZSBvZmYgb2YgcmlzayBjYWxjdWxhdGlvbnMgbGlrZSBwYXNzd29yZCByZXNldC4N Cg0KVGhlcmUgYXJlIGFsc28gc2lnbm91dCBldmVudHMgYXQgcnAncyB0byBsZXQgdGhlIE9QIGtu b3cuIFRoZXNlIGFyZSBub3QgY29tbWFuZHMgYnV0IG5vdGlmaWNhdGlvbiB0aGF0IGEgcmVzb3Vy Y2Ugc2Vzc2lvbiBpcyBjYW5jZWxsZWQuIElPVyBzaW5nbGUgc2lnbiBvdXQgbm90IGV4cGVjdGVk Lg0KDQpQaGlsDQoNCk9uIEp1biAyMSwgMjAxNywgYXQgMTo1OCBQTSwgSm9obiBCcmFkbGV5IDx2 ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgdGhv dWdodCB3ZSBkZWNpZGVkIHRoYXQgd2UgYXJlIG9ubHkgYWxsb3dpbmcgc2V0IG1lc3NhZ2VzIGZv cm0gdGhlIHNhbWUgZmFtaWx5IHRoYXQgYWdyZWUgb24gdG9wIGxldmVsIGNsYWltcy4NCg0KT3Ro ZXJ3aXNlIHRoZXJlIGNhbiBiZSBubyB0b3AgbGV2ZWwgY2xhaW1zIGFuZCB3ZSBhcmUgcmVhbGx5 IGRlZmluaW5nIGEgYWx0ZXJuYXRpdmUgZm9ybWF0IHRvIEpXVCBpbiBzb21lIHdheXMuDQoNCkpv aG4gQi4NCg0KT24gSnVuIDIxLCAyMDE3LCBhdCAzOjU0IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+ IHdyb3RlOg0KDQpJIGFncmVlIHdpdGggSm9obiB0aGF0IHRoZSBKV1QgdHlwZSBjb25mdXNpb24g cHJvYmxlbSBhbmQgdGhlIFNFVCBzdWIgcHJvYmxlbSBjYW4gYW5kIHNob3VsZCBiZSBkaXNjdXNz ZWQgc2VwYXJhdGVseS4gVGhlIHNlY2V2ZW50cyBXRyBpcyBwcm9iYWJseSBub3QgdGhlIHJpZ2h0 IHNldHRpbmcgdG8gZGlzY3VzcyB0aGUgZm9ybWVyLg0KDQpNeSBjb25jZXJuIHdpdGggdGhlIHN1 YiBjbGFpbSBpcyB0aGF0IHR3byBwcm9maWxlcyBtYXkgZGljdGF0ZSBjb25mbGljdGluZyBzZW1h bnRpY3MgKGUuZy4gUHJvZmlsZSBBIHNheXMgaXTigJlzIGEgcGhvbmUgbnVtYmVyLCBQcm9maWxl IEIgc2F5cyBpdOKAmXMgYW4gZW1haWwgYWRkcmVzcykuIElmIHRoZXNlIHByb2ZpbGVzIGRvbuKA mXQgcHJvdmlkZSBhbiBhbHRlcm5hdGUgd2F5IHRvIGRlY2xhcmUgc3ViamVjdCBvZiB0aGVpciBl dmVudHMsIHRoZW4gdGhleSBjYW5ub3QgYmUgcHJlc2VudCB3aXRoaW4gdGhlIHNhbWUgdG9rZW4u IFRoaXMgaW5jb21wYXRpYmlsaXR5IHRyYXAgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBjb3Vs ZCBiZSBlYXNpbHkgbWlzc2VkIGJ5IGdyb3VwcyBwcm9maWxpbmcgU0VULg0KDQotLQ0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBKb2huIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpEYXRl OiBXZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcgYXQgMTozOSBQTQ0KVG86IFlhcm9uIFNoZWZmZXIg PHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4NCkNj OiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+ LCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVz Y3VAZ29vZ2xlLmNvbT4+LCBBbm5hYmVsbGUgUmljaGFyZCA8cmljaGFubmFAYW1hem9uLmNvbTxt YWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+LCBNaWNoYWVsIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+ LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmc+PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zl ci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpTdWJqZWN0OiBS ZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQg ZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpJbiB0aGUgZW52ZWxvcGUgdHlwIGlzIGEgbWVkaWEvbWlt ZSB0eXBlLiAgUmVnaXN0ZXJpbmcgYXBwbGljYXRpb24vaWR0K2p3dCBpZiB3ZSByZWdpc3RlciBq d3QgYXMgYSBzdHJ1Y3R1cmVkIG5hbWUgc3VmaXguDQoNClVzaW5nIHRoZSBjdHkgaXMgYWxzbyBw b3NzaWJsZS4gICBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgd2hhdCBpcyBiZXR0ZXIgYnV0IHdlIGNh biBhZ3JlZSBvbiBhIGNvbnZlbnRpb24uDQoNCk5vdCBldmVyeXRoaW5nIGlzIGdvaW5nIHRvIGJl IGEgc2V0IHRva2VuIGxpa2Ugbm90IGV2ZXJ5IEpXUyBpcyBhIEpXVC4NCg0KSWYgd2UgYXJlIGdv aW5nIHRvIGRlZmluZSBwcm9jZXNzaW5nIHJ1bGVzIHRvIHN0b3AgY29sbGlzaW9ucyBhbmQgY29u ZnVzaW9uIGFyb3VuZCBKV1QgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcywgd2Ugc2hvdWxkIGp1c3Qg c3RhcnQgdXNpbmcgdGhlIHR5cCBwYXJhbWV0ZXIgYmFzZWQgb24gdGhlIGV4aXN0aW5nIHNwZWMu DQoNCkluIGdlbmVyYWwgY29udGVudCBzbmlmZmluZyBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25l IG9wdGlvbiBldmVudHVhbGx5IGdldHMgeW91IGludG8gdHJvdWJsZS4NCg0KSSBhbSBub3QgY29u dmluY2VkIHRoYXQgZm9yY2luZyB0aGVyZSB0byBiZSBubyBzdWIgYXQgdGhlIHRvcCBsZXZlbCBp cyBhIGdvb2QgaWRlYS4NCg0KSXQgaXMgbm90IHRoZSB3YXkgd2Ugc2hvdWxkIGRpZmZlcmVudGlh dGUgYmV0d2VlbiBTRVQgYW5kIGlkX3Rva2Vucy4NCg0KSWYgc3ViIGlzIG5vdCBhbGxvd2VkIGF0 IHRoZSB0b3AgbGV2ZWwgcGVvcGxlIHdpbGwgZG8gbm9uIFNFVCBKV1QgZm9yIHRoaW5ncyB3aGVy ZSB0aGUgc3ViamVjdCBpcyBzY29wZWQgdG8gdGhlIGlzcyBvZiB0aGUgdG9rZW4uDQoNCkkgdGhp bmsgZGVmaW5pbmcgc3ViIHRvIGJlIHBhcnQgb2YgdGhlIGV2ZW50IGZvciBjYXNlcyB3aGVyZSB0 aGUgc3ViIGlzIHNjb3BlZCBkaWZmZXJlbnRseSBmcm9tIHRoZSBpc3N1ZXIgb2YgdGhlIHRva2Vu IGlzIGZpbmUsIGJ1dCBzaG91bGQgbm90IGJlIHJlcXVpcmVkIGZvciBhbGwgZXZlbnQgdHlwZXMu DQoNCkkgdGhpbmsgd2Ugc2hvdWxkIHNvbHZlIHRoZSBjb25mdXNpb24gaXNzdWUgc2VwYXJhdGVs eSBmcm9tIHRoZSBzdWIgaXNzdWUuDQoNClNvcnJ5IEkgYW0gYXQgQ0lTIHNvIHRyeWluZyB0byBj YXRjaCB1cCBvbiBsaXN0cy4NCg0KSm9obiBCLg0KDQpPbiBKdW4gMTcsIDIwMTcsIGF0IDM6NDUg UE0sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tPj4gd3JvdGU6DQoNClNvIHRvIHN1bW1hcml6ZSB3aGF0IEknbSBzZWVpbmcg b24gdGhpcyB0aHJlYWQ6DQpFdmVyeWJvZHkgYWdyZWVzIHdpdGggTWFyaXVzJ3Mgc2hvcnQtdGVy bSBzb2x1dGlvbiwgc3BlY2lmaWMgcnVsZXMgZm9yICJzdWIiIGFuZCAiaXNzIiB0aGF0IGNhbiBi ZSBkZWZpbmVkIGluIHRoZSBTRVQgc3BlYy4NCkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEg bG9uZy10ZXJtICJ1c2FnZSIgY2xhaW0gKCJ0eXBlIiBpcyB0YWtlbikgdGhhdCBzaG91bGQgYmUg ZGVmaW5lZCBlbHNld2hlcmUsIGUuZy4gaW4gdGhlIEpXVCBCQ1AuDQpEaWQgSSBtaXNzIGFueXRo aW5nPw0KQnkgdGhlIHdheSwgaWYgd2UgZG8gYWRkIGEgInVzYWdlIiBjbGFpbSwgd2UgbmVlZCB0 byBhbHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQu DQpUaGFua3MsDQogICAgWWFyb24NCg0KT24gMTUvMDYvMTcgMjI6MDgsIEp1c3RpbiBSaWNoZXIg d3JvdGU6DQorMSB0byB0aGlzIGFzIHdlbGwuDQoNCiDigJQgSnVzdGluDQoNCk9uIEp1biAxNSwg MjAxNywgYXQgMTowOSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29t PG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiB3cm90ZToNCg0KKzEgdG8gd2hhdCBBbm5h YmVsbGUgc2FpZC4NCg0KQWxzbywgTWlrZSB5b3UgYXJlIG1pc3NpbmcgdGhlIG90aGVyIHJlcXVp cmVtZW50LCBmb3IgUlBzIHRvIHNlbmQgZXZlbnRzIHRvIGFuIElkUC4gVGhlIGlzcytzdWIgcGFp ciBhdCB0aGUgdG9wIGxldmVsIGlzIGJyb2tlbiBpbiB0aGlzIGNhc2UuDQoNCk1hcml1cw0KDQpP biBXZWQsIEp1biAxNCwgMjAxNyBhdCA1OjMzIFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KKzENCg0K UGhpbA0KDQpPbiBKdW4gMTQsIDIwMTcsIGF0IDU6MjUgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5u YWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4g d3JvdGU6DQpNaWtlLA0KDQpZb3VyIGV4cGxhbmF0aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1w cm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNpZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVu SUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFz IGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsIGlzc3VlcyB3aXRoIGl0Og0KDQoxLiAgICAgICBUaGUg Y2FsbGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBi ZSBjZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tl bi4gQW55IHBhcnR5IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBo YXMgbm8gd2F5IHRvIHZlcmlmeSBpdHMgcHJvdmVuYW5jZS4NCg0KMi4gICAgICAgQW55IGZ1dHVy ZSBJRCBUb2tlbiBkaXN0cmlidXRpb24gbWV0aG9kIG5lZWRzIHRvIHNvbHZlIHRoaXMgcHJvYmxl bSBhZ2Fpbi4NCg0KMy4gICAgICBObyBvdGhlciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2Ug dGhlICJub25jZeKAnSBjbGFpbS4NCg0KNC4gICAgICBUaGlzIGlzIG9ubHkgYSBzb2x1dGlvbiBm b3IgSUQgVG9rZW5zLiBFdmVyeSBvdGhlciBKV1QgcHJvZmlsZSB0aGF0IGNhcmVzIGFib3V0IGRp c2FtYmlndWF0aW9uIGhhcyB0byBpbnZlbnQgaXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxl bS4NCg0KV2Uga25vdyBmcm9tIGV4cGVyaWVuY2UgdGhhdCBuYW1pbmcgY29sbGlzaW9ucyBhbmQg cmVwbGF5IGF0dGFja3MgYXJlIGJvdGggdGhpbmdzIHRoYXQgaGFwcGVuLiBXaGF04oCZcyBiZWlu ZyBwcm9wb3NlZCBpcyBhIHNpbXBsZSwgZGVmZW5zaXZlIG1lYXN1cmUgYWdhaW5zdCB0aGVzZSBy aXNrcy4gWW91IGJyb3VnaHQgdXAgSldUIGxpYnJhcmllczogYSBnZW5lcmFsIHNvbHV0aW9uIGFj dHVhbGx5IG1ha2VzIGl0IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJhcmllcyBmb3IgSldUIHBh cnNpbmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQgaGFuZGxlIGRpc2Ft YmlndWF0aW9uIGZvciBhbnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aCB0aGUgc3RhdHVzIHF1 byBlYWNoIHByb2ZpbGUgd291bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMuDQoNCi0tDQpBbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50 IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnPj4gb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwg SnVuZSAxNCwgMjAxNyBhdCAxOjE2IFBNDQpUbzogTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNj dUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pg0KQ2M6ICJSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20+PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8 bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4sIEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpA c2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+ Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBj b25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KWW914oCZdmUgaGVhcmQgb2Yg4oCc cHJlbWF0dXJlIG9wdGltaXphdGlvbuKAnS4gIEnigJlkIGNoYXJhY3Rlcml6ZSB0aGUgcHJvcG9z YWxzIGluIHRoaXMgdGhyZWFkIGFzIOKAnHByZW1hdHVyZSBwZXNzaW1hdGlvbuKAnSDigJMgbWFr aW5nIHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hvdWxkIGJlIHNpbXBsZSBjb21wbGV4LCB3aXRob3V0 IGRhdGEgc2hvd2luZyB0aGVyZeKAmXMgYW55IG5lZWQgdG8gZG8gc28uDQoNCk1hbmRhdG9yeSBz b2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGluIHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRo YXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZlLiAgSXTi gJlzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hlZCB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZvciBh IFNFVCB0byBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4g4oCTIHNlZSBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRtbDxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRldmVudF9jdXJyZW50X21zZzAwNDI4Lmh0 bWwmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1lS0xUUVBtWXJWM1RoZkRibjkw U0NzNTVVUk9UUGluX2xnYzZSZHI1WG93JmU9Pi4gIElmIHBlb3BsZSBoYXZlIGRhdGEgc2hvd2lu ZyB0aGF0IHRoaXMgaXMgcG9zc2libGUgd2l0aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9r ZW5zIG9yIG90aGVyIHJlYWwgSldUIGRlcGxveW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZp Y3MsIHNvIHRoYXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEgdG8gaW5mb3JtIGFwcHJvcHJpYXRlIGVu Z2luZWVyaW5nIGNob2ljZXMgb24gb3VyIHBhcnQuDQoNClRoZSBwcm9wb3NlZCDigJxzb2x1dGlv bnPigJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5v cm1hbCB3YXksIG9yIHJlcXVpcmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNs eSBzaW1wbGUgdGhpbmdzIHVubmVjZXNzYXJpbHkgY29tcGxleC4gIFllcywgdGhlbiB0aGUgcmVz dWx0IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1dCBhIGNvbnNlcXVlbmNl IG9mIHRoaXMgaXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxkIGhhdmUgdG8gYmUgdXNl ZCwgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiAgVGhlIG1vcmUgdW53aWVsZHkg d2UgbWFrZSBpdCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVsb3BlcnMgYXJlIHRv IGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuICBLZWVwaW5nIGl0IHNpbXBs ZSBpcyB0aGUga2V5IHRvIGFkb3B0aW9uLiAgU3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0 aGV5IGFyZSBhY3R1YWxseSB1c2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE0NClRvOiBNYXJpdXMgU2N1 cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bT4+OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0 bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMgTWFpbGlu ZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNp b24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KRWNob2luZyBNYXJpdXPigJlzIHF1ZXN0aW9u OiBjYW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieSDigJxpbnRlbmTigJ0/DQoNClRvIHlv dXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3b3VsZCBiZSB0aGUg WC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJvcGVydHkgdGhhdCBk ZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBhbmQgdGhhdCBhIHJlY2lw aWVudCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpX VCBiZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4gc29tZSBjb250ZXh0Lg0KDQotLQ0KQW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8 aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208 bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBKdW5lIDEzLCAy MDE3IGF0IDExOjA1IEFNDQpUbzogSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJh dW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpDYzog SUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50 QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nl c3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCk9uIFR1ZSwgSnVu IDEzLCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZy YXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+PiB3cm90 ZToNCkFuZCBhIDJuZCBxdWVzdGlvbi4NCg0KV2hhdCBzZW1hbnRpY3Mgd291bGQgInVzYWdlIiBw cm92aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICJpbnRlbmQiLCAiYXVkaWVuY2Ui LCBhbmQgInNjb3BlIj8NCg0KImF1ZCIgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdldCBj bGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0aG9y aXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1cml0eSBldmVu dD8pDQoNCiJzY29wZSIgaXMgbm90IHVzZWQgYnkgU0VULg0KDQpJIGRvbid0IGtub3cgd2hhdCBk byB5b3UgbWVhbiBieSAiaW50ZW5kIiAob3IgaW50ZW50KT8NCg0KDQoNCg0KSGVuaw0KDQpPbiAw Ni8xMy8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSB3cm90ZToNClRo YW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyIQ0KDQpJIHRoaW5rIHRoZSBhc3N1bXB0aW9u cyBpbmhlcmVudCBpbiAzLjkgYXJlIGZsYXdlZDoNCg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0 aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQg b2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0 aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9h Y2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBt aXN0YWtlbiBmb3IgSldUcyBmcm9tIGEgY3VycmVudCBzcGVjLg0KDQrCt0l0IGlzIHVucmVhbGlz dGljIHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRoZXJlIHRvIHRoZSDigJxkaWZmZXJlbnQg a2V5cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPigJ0gcnVsZS4gV2hldGhlciBtYW5kYXRl ZCBieSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVycyB3aWxsIGlnbm9yZSB0aGlzIGJlY2F1 c2UgbWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhhbiBtYW5hZ2luZyBOIGRpZmZlcmVudCBr ZXlzLg0KDQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBjbGFpbXMuDQoNCisx IGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci4N Cg0KLS0NCg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQpJZGVudGl0eSBTZXJ2aWNlcw0K DQoqRnJvbTogKklkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFy ZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQoqRGF0ZTogKk1vbmRh eSwgSnVuZSAxMiwgMjAxNyBhdCAzOjE4IFBNDQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1IDxtc2N1 cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQoqQ2M6ICpB ZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+Piwg Im1hdGFrZSwgbm92IiA8bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4+LCBJRCBF dmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0 Zi5vcmc+PiwgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbT4+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9u IGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoN CkFncmVlZC4gTm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB3 aGF0IHNob3VsZCBiZSBpbiAzLjkuDQoNCk9uIE1vbiwgSnVuIDEyLCAyMDE3IGF0IDM6MTUgUE0s IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tPjxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20+Pj4gd3JvdGU6DQoNCiAgICBUaGFua3MgZm9yIHRoZSBwb2ludGVyIERp Y2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pDQoNCiAgICBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5 ICIyLjcuIENyb3NzLUpXVCBDb25mdXNpb24iIGFuZCB0aGUNCiAgICBtaXRpZ2F0aW9uIGlzIGlu ICIzLjkuIFVzZSBNdXR1YWxseSBFeGNsdXNpdmUgVmFsaWRhdGlvbiBSdWxlcyBmb3INCiAgICBE aWZmZXJlbnQgS2luZHMgb2YgSldUcyIsIHNwZWNpZmljYWxseSAiVXNlIGRpZmZlcmVudCBzZXRz IG9mDQogICAgcmVxdWlyZWQgY2xhaW1zLi4uIiwgIlVzZSBkaWZmZXJlbnQga2V5cyBmb3IgZGlm ZmVyZW50IGtpbmRzIG9mDQogICAgSldUcy4iIGFuZCAiVXNlIGRpZmZlcmVudCBpc3N1ZXJzIGZv ciBkaWZmZXJlbnQga2luZHMgb2YgSldUcy4iLg0KDQogICAgSSBzdGlsbCB0aGluayB0aGF0IGEg InR5cGUiIGNsYWltIHdvdWxkIGJyaW5nIGEgbG90IG9mIGNsYXJpdHkgYW5kDQogICAgc2FmZXR5 Lg0KDQoNCiAgICBNYXJpdXMNCg0KICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTo1OSBQTSwg RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tPg0KICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tPj4+IHdyb3RlOg0KDQogICAgICAgIFlhcm9uLCBNaWtlIGFuZCBJIGp1c3QgcHVi bGlzaGVkIGFuIEJDUCBJRCBmb3IgSldUDQogICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZv Lz9wPTE2OTA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZkPUR3TUdhUSZjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdK eFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlf M3pSb2FpMTE1YyZzPWE3WHZaNWpUYnRBMnZqZmFISU1idkVPcFNCQmxCcGRzRGtJVFpNY1VJVVEm ZT0+DQoNCiAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMg PGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4NCiAgICAgICAgPG1h aWx0bzphZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+Pj4gd3JvdGU6 DQoNCiAgICAgICAgICAgIEkgd2FzIGluaXRpYWxseSBhIGZhbiBvZiBrZWVwaW5nIFNFVFMgdG8g YmUgdmVyeSBzaW1pbGFyIHRvDQogICAgICAgICAgICBpZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5r IHRoaXMgaXMgYSBiZXR0ZXIgcGxhbi4NCg0KICAgICAgICAgICAgT24gVGh1LCBKdW4gOCwgMjAx NyBhdCA2OjU2IFBNIG1hdGFrZSwgbm92IDxub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtl LmpwPg0KICAgICAgICAgICAgPG1haWx0bzpub3ZAbWF0YWtlLmpwPG1haWx0bzpub3ZAbWF0YWtl LmpwPj4+IHdyb3RlOg0KDQogICAgICAgICAgICAgICAgKzEgZXNwZWNpYWxseSBmb3IgInR5cGUi DQoNCiAgICAgICAgICAgICAgICAyMDE3LTA2LTA5IDEwOjMyIEdNVCswOTowMCBQaGlsIEh1bnQg KElETSkNCiAgICAgICAgICAgICAgICA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPj4+Og0KDQogICAgICAgICAgICAgICAgICAgICsxDQoNCiAgICAgICAg ICAgICAgICAgICAgUGhpbA0KDQoNCiAgICAgICAgICAgICAgICAgICAgID4gT24gSnVuIDgsIDIw MTcsIGF0IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3UNCiAgICAgICAgICAgICAgICAgICAgPG1z Y3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KICAgICAg ICAgICAgICAgICAgICA8bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPj4+IHdyb3RlOg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAg ICAgICAgICAgICAgICAgPiBUaGVyZSB3ZXJlIGEgY291cGxlIG9mIHByb3Bvc2FscyBvbiBob3cg dG8NCiAgICAgICAgICAgICAgICAgICAgZGlzdGluZ3Vpc2ggU0VUcyBmcm9tIElkIFRva2VucyBh bmQgQWNjZXNzIFRva2VucyBpbg0KICAgICAgICAgICAgICAgICAgICBzdWNoIGEgd2F5IHRoYXQg bmFpdmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90DQogICAgICAgICAgICAgICAgICAgIGNvbmZ1 c2Ugb25lIGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJpdHkNCiAgICAgICAgICAgICAg ICAgICAgdnVsbmVyYWJpbGl0aWVzLg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAg ICAgICAgICAgICAgPiBUaGVyZSBpcyBhbHNvIGFub3RoZXIgaW1wb3J0YW50IHJlcXVpcmVtZW50 OiB0aGUNCiAgICAgICAgICAgICAgICAgICAgU0VUIGlzc3VlciBpbiBzb21lIGNhc2VzIG11c3Qg YmUgZGlmZmVyZW50IGZyb20gdGhlDQogICAgICAgICAgICAgICAgICAgICJzdWIiIGlzc3Vlci4g VGhpcyBpcyB0aGUgY2FzZSBvZiBhbiBSUCBzZW5kaW5nIFNFVHMNCiAgICAgICAgICAgICAgICAg ICAgdG8gYW4gSWRQLg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAg ICAgPiBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGUNCiAgICAg ICAgICAgICAgICAgICAgZm9sbG93aW5nOg0KICAgICAgICAgICAgICAgICAgICAgPiAtIGJvdGgg InN1YiIgYW5kICJpc3MiIHRvIGJlIGRlZmluZWQgYXQgdGhlIGV2ZW50DQogICAgICAgICAgICAg ICAgICAgIGxldmVsDQogICAgICAgICAgICAgICAgICAgICA+IC0gImlzcyIgYXQgZXZlbnQgbGV2 ZWwgYW5kIGF0IHRvcCBTRVQgbGV2ZWwgY2FuDQogICAgICAgICAgICAgICAgICAgIGJlIGRpZmZl cmVudA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGFuZCAic3ViIiBhdCBldmVudCBs ZXZlbCBjYW4gYmUgZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAgIGFjcm9zcyBldmVudHMg aW4gdGhlIHNhbWUgU0VUDQogICAgICAgICAgICAgICAgICAgICA+IC0gInN1YiIgc2hvdWxkIE5P VCBiZSBwcmVzZW50IGF0IHRoZSB0b3AgU0VUDQogICAgICAgICAgICAgICAgICAgIGxldmVsICh0 aGlzIHNvbHZlcyB0aGUgZGlzYW1iaWd1YXRpb24pLCBwbGVhc2Ugbm90ZQ0KICAgICAgICAgICAg ICAgICAgICAic2hvdWxkIiBhbmQgbm90ICJtdXN0Ig0KICAgICAgICAgICAgICAgICAgICAgPg0K ICAgICAgICAgICAgICAgICAgICAgPiBUaGlzIHNvbHV0aW9uIGFsc28gYWxsb3dzIGRpZmZlcmVu dCBwcm9maWxlcyB0aGF0DQogICAgICAgICAgICAgICAgICAgIGRlZmluZSBldmVudCB0eXBlcyB0 byBkZWZpbmUgYWRkaXRpb25hbCBjbGFpbXMNCiAgICAgICAgICAgICAgICAgICAgcmVsYXRlZCB0 byBzdWIgKGxpa2UgZW1haWwgb3IgcGhvbmVfbnVtYmVyKSBhbmQNCiAgICAgICAgICAgICAgICAg ICAgc2luY2UgYWxsIHRoZXNlIGNsYWltcyB3aWxsIGJlIGF0IHRoZSBldmVudCBsZXZlbA0KICAg ICAgICAgICAgICAgICAgICB0aGVyZSB3aWxsIGJlIG5vIGNvbGxpc2lvbnMgb3IgYW1iaWd1aXR5 Lg0KICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBBbm90aGVy IHByb3Bvc2FsICh3aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvDQogICAgICAgICAgICAgICAgICAg IGRlZmluZSBhIGNvbXBvc2l0ZSAiYXVkIiBjbGFpbS4gVGhpcyBpcyBub3Qgc29sdmluZw0KICAg ICAgICAgICAgICAgICAgICB0aGUgcmVxdWlyZW1lbnQgZm9yIGEgZGlzdGluY3QgIFNFVCBpc3N1 ZXIuIEFsc28sDQogICAgICAgICAgICAgICAgICAgIGhhdmluZyB0aGUgc2FtZSBjbGFpbSBuYW1l IGhhdmluZyBkaWZmZXJlbnQgc3ludGF4DQogICAgICAgICAgICAgICAgICAgIGluIGRpZmZlcmVu dCB0b2tlbiB0eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi4NCiAgICAgICAgICAgICAgICAg ICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5kIHlldCBhbm90aGVyIHByb3Bvc2FsIHdh cyB0byBpbnRyb2R1Y2UgYSBuZXcNCiAgICAgICAgICAgICAgICAgICAgY2xhaW0gZm9yIEpXVHMg dGhhdCBkZWZpbmVzIGEgInR5cGUiLiBUaGlzIGlzIG5vdA0KICAgICAgICAgICAgICAgICAgICBw cmFjdGljYWwgaW4gdGhlIHNob3J0IHRlcm0sIGFuZCBpdCBhbHNvIGlzIG5vdA0KICAgICAgICAg ICAgICAgICAgICBzb2x2aW5nIHRoZSBkaXN0aW5jdCBpc3N1ZXIgcmVxdWlyZW1lbnQsIGJ1dCBJ IHRoaW5rDQogICAgICAgICAgICAgICAgICAgIHRoaXMgaXMgc29tZXRoaW5nIHRoZSBKV1QgZ3Jv dXAgc2hvdWxkIHNlcmlvdXNseQ0KICAgICAgICAgICAgICAgICAgICBjb25zaWRlci4NCiAgICAg ICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gVGhvdWdodHM/DQogICAg ICAgICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IE1hcml1cw0KDQogICAg ICAgICAgICAgICAgICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgICAgICAgICAgICAgICAgICA+IElkLWV2ZW50IG1haWxpbmcgbGlzdA0K ICAgICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRA aWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYu b3JnPj4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZtaVJpSHFX Z2Z4cW1nJnM9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZlPQ0K DQogICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgICAgICAgICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0K ICAgICAgICAgICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn Pj4NCiAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01H YVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJp UnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFs N2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1 eWc3b01VN1RtR01TV1dzJmU9Pg0KDQogICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgICAgICBJZC1ldmVudCBt YWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAgICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50 QGlldGYub3JnPj4NCiAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZk PUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtI c2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0 RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgICAgIC0tDQogICAgICAgICAgICBB ZGFtIERhd2VzIHwgU3IuIFByb2R1Y3QgTWFuYWdlciB8YWRhd2VzQGdvb2dsZS5jb208bWFpbHRv OmFkYXdlc0Bnb29nbGUuY29tPg0KICAgICAgICAgICAgPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+PiB8KzEgNjUwLTIxNC0yNDEwPHRlbDolMkIxJTIw NjUwLTIxNC0yNDEwPg0KICAgICAgICAgICAgPHRlbDooNjUwKSUyMDIxNC0yNDEwPHRlbDolMjg2 NTAlMjklMjAyMTQtMjQxMD4+DQoNCiAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICBJZC1ldmVudCBtYWlsaW5nIGxp c3QNCiAgICAgICAgICAgIElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0K ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQt MDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01T V1dzJmU9Pg0KDQogICAgICAgIC0tDQogICAgICAgIFN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJF IDxodHRwOi8vaGFyZHR3YXJlLmNvbS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4 UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8z elJvYWkxMTVjJnM9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZl PT4+IG1haWwgbGlzdCB0bw0KICAgICAgICBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtp bmcgb24hDQoNCg0KDQotLQ0KDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSA8aHR0cDovL2hh cmR0d2FyZS5jb20vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZz PWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJWODAmZT0+PiBtYWlsIGxp c3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxp bmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xO S2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMm cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFp bGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1 YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBt YWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4N Cmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0w MFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNX V3MmZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KDQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQNCg0K --_000_E967B191C08B4C96927E8A22E0673AF9amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLm0tNDYyOTg0MjU2OTM4 NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTptXy00NjI5ODQy NTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnAubS00NjI5ODQyNTY5Mzg1MTU5 OTg4bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoLCBsaS5tLTQ2Mjk4NDI1Njkz ODUxNTk5ODhtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTQ2Mjk4 NDI1NjkzODUxNTk5ODhtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLW5hbWU6bV8tNDYyOTg0MjU2OTM4NTE1OTk4OG05MDk0MDg5MjM5NjY4NTcwMzEybXNv bGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZhaXIgcG9pbnQuIElmIHdl IGRvIG5vdCBpbnRlbmQgdG8gc3VwcG9ydCBtdWx0aXBsZSBwcm9maWxlcyB3aXRoaW4gYSBzaW5n bGUgU0VULCB0aGVuIEnigJltIGxlc3MgY29uY2VybmVkIGFib3V0IGxlYXZpbmcgc3ViIHNlbWFu dGljcyB1cCB0byB0aGUgcHJvZmlsZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklkZW50aXR5IFNlcnZpY2VzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5NYXJpdXMgU2N1cnRlc2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyBhdCAyOjU4IFBNPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7 cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O1BoaWwgSHVudCAo SURNKSZxdW90OyAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7LCBKb2huIEJyYWRsZXkgJmx0 O3ZlN2p0YkB2ZTdqdGIuY29tJmd0OywgSGVuayBCaXJraG9seiAmbHQ7aGVuay5iaXJraG9sekBz aXQuZnJhdW5ob2Zlci5kZSZndDssIEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZn dDssIFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDssIE1pY2hhZWwg Sm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDssIElEIEV2ZW50cw0KIE1h aWxpbmcgTGlzdCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFu ZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGFtcGxlIGZvciBtdWx0aXBsZSBldmVudHMgd2l0 aGluIHNhbWUgcHJvZmlsZTogSWRQIGFjY291bnQgaXMgZGlzYWJsZWQgKGJlY2F1c2Ugb2YgaGlq YWNraW5nKSwgdGhpcyBjYW4gbGVhZCB0byB0d28gZXZlbnRzOg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gJnF1b3Q7YWNjb3VudC1kaXNhYmxlZCZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4g JnF1b3Q7c2Vzc2lvbnMtcmV2b2tlZCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyaXVzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gMjEs IDIwMTcgYXQgMjo1NCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9 Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1h em9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBzcGVj IHNheXMgdGhhdCB0aGUgZXZlbnRzIGNsYWltIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBleHByZXNz IG11bHRpcGxlIGxvZ2ljYWwgZXZlbnRzLiBJZiBpdOKAmXMgYWxzbyBub3QgdXNlZA0KIHRvIGV4 cHJlc3MgZXZlbnRzIGZyb20gZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQgY29ycmVzcG9uZCB0byB0 aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChlLmcuIGFuIE9JREMgYmFja2NoYW5uZWwgbG9nb3V0IGV2 ZW50IGFsb25nc2lkZSBhIGh5cG90aGV0aWNhbCBSSVNDIGxvZ291dCBldmVudCksIHRoZW4gSeKA mW0gbm90IHN1cmUgd2hhdCB1c2UgY2FzZSB0aGF0IGxlYXZlcyBmb3IgbXVsdGlwbGUgZXZlbnRz IGluIG9uZSBTRVQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAyMSwg MjAxNyBhdCAyOjEyIFBNPGJyPg0KPGI+VG86IDwvYj5Kb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9 Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIu Y29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OywgSGVuayBCaXJraG9seiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0i X2JsYW5rIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDssIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5r Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OywNCiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVm PSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0ZXNj dUBnb29nbGUuY29tPC9hPiZndDssIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OywgTWljaGFlbCBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7LA0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0 bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9h PiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3Ig SWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3VlcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VwYXJhdGUgb3IgY29tYmluZWQgbWF5IGJlIGV2b2x2 aW5nLiBNaWtlIHdhbnRzIHRvIGtlZXAgdGhlIGN1cnJlbnQgYmFja2NoYW5uZWwgbG9nb3V0IHZl cnkgbmFycm93bHkgc2NvcGVkLiBIZSBzdWdnZXN0ZWQgcmlzYyBkZWZpbmUgaXRzIG93biBkdXBs aWNhdGUgZGVmaW5pdGlvbnMgYW5kIG1lYW5pbmdzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJtXy00NjI5ODQyNTY5Mzg1MTU5OTg4QXBwbGVNYWlsU2lnbmF0dXJlIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9Im1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGF0IGxlYWRzIG1lIHRvIGJlbGlldmUgd2Ugd2lsbCBoYXZlIG11 bHRpLXR5cGUgZXZlbnRzIGluIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXy00NjI5ODQyNTY5Mzg1MTU5OTg4QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f LTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TZXNzaW9uIGNhbmNlbGxhdGlvbiBjYW4gb2NjdXIgZm9yIG1hbnkgcmVhc29ucy4g T25lIG9mIHRoZSBkaWZmZXJlbnRpYXRvcnMgd2UgaGFkIHRyaWVkIHRvIG1ha2Ugd2FzIGFuIGFz c3VtcHRpb24gdGhhdCB1c2VyIGluaXRpYXRlZCBldmVudHMgd291bGQgYmUgcGFydCBvZiBjb25u ZWN0LiBSaXNrIHdvdWxkDQogY292ZXIgdmFyaWF0aW9ucyB0aGF0IGRyaXZlIG9mZiBvZiByaXNr IGNhbGN1bGF0aW9ucyBsaWtlIHBhc3N3b3JkIHJlc2V0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtXy00NjI5ODQyNTY5Mzg1MTU5OTg4QXBwbGVNYWlsU2lnbmF0dXJl Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Im1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZSBhcmUgYWxzbyBzaWdub3V0IGV2ZW50cyBhdCBycCdz IHRvIGxldCB0aGUgT1Aga25vdy4gVGhlc2UgYXJlIG5vdCBjb21tYW5kcyBidXQgbm90aWZpY2F0 aW9uIHRoYXQgYSByZXNvdXJjZSBzZXNzaW9uIGlzIGNhbmNlbGxlZC4gSU9XIHNpbmdsZSBzaWdu IG91dCBub3QgZXhwZWN0ZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCk9uIEp1biAyMSwgMjAxNywgYXQgMTo1OCBQTSwgSm9obiBCcmFk bGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5r Ij52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhvdWdodCB3ZSBkZWNpZGVkIHRo YXQgd2UgYXJlIG9ubHkgYWxsb3dpbmcgc2V0IG1lc3NhZ2VzIGZvcm0gdGhlIHNhbWUgZmFtaWx5 IHRoYXQgYWdyZWUgb24gdG9wIGxldmVsIGNsYWltcy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk90aGVyd2lzZSB0aGVyZSBjYW4gYmUgbm8gdG9w IGxldmVsIGNsYWltcyBhbmQgd2UgYXJlIHJlYWxseSBkZWZpbmluZyBhIGFsdGVybmF0aXZlIGZv cm1hdCB0byBKV1QgaW4gc29tZSB3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEp1biAyMSwgMjAxNywgYXQg Mzo1NCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpy aWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCBK b2huIHRoYXQgdGhlIEpXVCB0eXBlIGNvbmZ1c2lvbiBwcm9ibGVtIGFuZCB0aGUgU0VUIHN1YiBw cm9ibGVtIGNhbiBhbmQgc2hvdWxkIGJlIGRpc2N1c3NlZCBzZXBhcmF0ZWx5LiBUaGUgc2VjZXZl bnRzIFdHIGlzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQgc2V0dGluZyB0byBkaXNjdXNzIHRoZSBm b3JtZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGNvbmNlcm4gd2l0aCB0aGUg c3ViIGNsYWltIGlzIHRoYXQgdHdvIHByb2ZpbGVzIG1heSBkaWN0YXRlIGNvbmZsaWN0aW5nIHNl bWFudGljcyAoZS5nLiBQcm9maWxlIEEgc2F5cyBpdOKAmXMgYSBwaG9uZSBudW1iZXIsIFByb2Zp bGUgQiBzYXlzIGl04oCZcyBhbiBlbWFpbCBhZGRyZXNzKS4gSWYgdGhlc2UgcHJvZmlsZXMgZG9u 4oCZdCBwcm92aWRlDQogYW4gYWx0ZXJuYXRlIHdheSB0byBkZWNsYXJlIHN1YmplY3Qgb2YgdGhl aXIgZXZlbnRzLCB0aGVuIHRoZXkgY2Fubm90IGJlIHByZXNlbnQgd2l0aGluIHRoZSBzYW1lIHRv a2VuLiBUaGlzIGluY29tcGF0aWJpbGl0eSB0cmFwIHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQg Y291bGQgYmUgZWFzaWx5IG1pc3NlZCBieSBncm91cHMgcHJvZmlsaW5nIFNFVC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQotLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KSWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Sm9obiBCcmFkbGV5 ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52 ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0ibS00NjI5 ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldl ZG5lc2RheSwgSnVuZSAyMSwgMjAxNyBhdCAxOjM5IFBNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9 Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjwvYj5ZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9iPkp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Oywg TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7LA0KIEFubmFi ZWxsZSBSaWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OywgUGhpbCBIdW50ICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7LCBNaWNoYWVsIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDssDQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWQtZXZl bnRAaWV0Zi5vcmc8L2E+Jmd0OywgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj5oZW5rLmJpcmto b2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNz PSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNp b24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSW4gdGhlIGVudmVsb3BlIHR5 cCBpcyBhIG1lZGlhL21pbWUgdHlwZS4mbmJzcDsgUmVnaXN0ZXJpbmcgYXBwbGljYXRpb24vaWR0 JiM0Mztqd3QgaWYgd2UgcmVnaXN0ZXIgand0IGFzIGEgc3RydWN0dXJlZCBuYW1lIHN1Zml4LiAm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NClVzaW5nIHRoZSBjdHkgaXMgYWxzbyBwb3NzaWJsZS4gJm5ic3A7IEkgbmVlZCB0 byB0aGluayBhYm91dCB3aGF0IGlzIGJldHRlciBidXQgd2UgY2FuIGFncmVlIG9uIGEgY29udmVu dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCk5vdCBldmVyeXRoaW5nIGlzIGdvaW5nIHRvIGJlIGEg c2V0IHRva2VuIGxpa2Ugbm90IGV2ZXJ5IEpXUyBpcyBhIEpXVC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSWYgd2Ug YXJlIGdvaW5nIHRvIGRlZmluZSBwcm9jZXNzaW5nIHJ1bGVzIHRvIHN0b3AgY29sbGlzaW9ucyBh bmQgY29uZnVzaW9uIGFyb3VuZCBKV1QgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcywgd2Ugc2hvdWxk IGp1c3Qgc3RhcnQgdXNpbmcgdGhlIHR5cCBwYXJhbWV0ZXIgYmFzZWQgb24gdGhlIGV4aXN0aW5n IHNwZWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti YWNrZ3JvdW5kOndoaXRlIj4NCkluIGdlbmVyYWwgY29udGVudCBzbmlmZmluZyBpZiB0aGVyZSBp cyBtb3JlIHRoYW4gb25lIG9wdGlvbiBldmVudHVhbGx5IGdldHMgeW91IGludG8gdHJvdWJsZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KSSBhbSBub3QgY29udmluY2VkIHRoYXQgZm9yY2luZyB0aGVyZSB0byBiZSBu byBzdWIgYXQgdGhlIHRvcCBsZXZlbCBpcyBhIGdvb2QgaWRlYS4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N Ckl0IGlzIG5vdCB0aGUgd2F5IHdlIHNob3VsZCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gU0VUIGFu ZCBpZF90b2tlbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQpJZiBzdWIgaXMgbm90IGFsbG93ZWQgYXQgdGhlIHRvcCBsZXZlbCBw ZW9wbGUgd2lsbCBkbyBub24gU0VUIEpXVCBmb3IgdGhpbmdzIHdoZXJlIHRoZSBzdWJqZWN0IGlz IHNjb3BlZCB0byB0aGUgaXNzIG9mIHRoZSB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSSB0aGluayBkZWZp bmluZyBzdWIgdG8gYmUgcGFydCBvZiB0aGUgZXZlbnQgZm9yIGNhc2VzIHdoZXJlIHRoZSBzdWIg aXMgc2NvcGVkIGRpZmZlcmVudGx5IGZyb20gdGhlIGlzc3VlciBvZiB0aGUgdG9rZW4gaXMgZmlu ZSwgYnV0IHNob3VsZCBub3QgYmUgcmVxdWlyZWQgZm9yIGFsbCBldmVudCB0eXBlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KSSB0aGluayB3ZSBzaG91bGQgc29sdmUgdGhlIGNvbmZ1c2lvbiBpc3N1ZSBzZXBhcmF0 ZWx5IGZyb20gdGhlIHN1YiBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KU29ycnkgSSBhbSBhdCBDSVMgc28g dHJ5aW5nIHRvIGNhdGNoIHVwIG9uIGxpc3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpKb2huIEIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQpPbiBKdW4gMTcsIDIwMTcsIGF0IDM6NDUgUE0sIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQpTbyB0byBzdW1tYXJpemUgd2hhdCBJJ20gc2VlaW5nIG9uIHRoaXMgdGhyZWFk OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KRXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRl cm0gc29sdXRpb24sIHNwZWNpZmljIHJ1bGVzIGZvciAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90 O2lzcyZxdW90OyB0aGF0IGNhbiBiZSBkZWZpbmVkIGluIHRoZSBTRVQgc3BlYy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICZxdW90O3VzYWdl JnF1b3Q7IGNsYWltICgmcXVvdDt0eXBlJnF1b3Q7IGlzIHRha2VuKSB0aGF0IHNob3VsZCBiZSBk ZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJDUC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCkRp ZCBJIG1pc3MgYW55dGhpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpCeSB0aGUgd2F5LCBpZiB3ZSBkbyBh ZGQgYSAmcXVvdDt1c2FnZSZxdW90OyBjbGFpbSwgd2UgbmVlZCB0byBhbHNvIHVzZSBpdCBpbiB0 aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpU aGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDsmbmJzcDsmbmJzcDsgWWFyb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCk9uIDE1LzA2LzE3IDIyOjA4LCBK dXN0aW4gUmljaGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiYjNDM7MSB0byB0 aGlzIGFzIHdlbGwuPHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KT24gSnVuIDE1LCAyMDE3LCBhdCAxOjA5IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBo cmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KJiM0MzsxIHRvIHdoYXQgQW5uYWJlbGxlIHNhaWQuPHNwYW4gY2xhc3M9Im0t NDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KQWxzbywgTWlrZSB5b3UgYXJlIG1pc3NpbmcgdGhlIG90aGVyIHJlcXVpcmVtZW50LCBmb3Ig UlBzIHRvIHNlbmQgZXZlbnRzIHRvIGFuIElkUC4gVGhlIGlzcyYjNDM7c3ViIHBhaXIgYXQgdGhl IHRvcCBsZXZlbCBpcyBicm9rZW4gaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KTWFyaXVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KT24gV2VkLCBKdW4gMTQsIDIwMTcgYXQgNTozMyBQTSwgUGhp bCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xl LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQomIzQzOzE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy00NjI5ODQyNTY5Mzg1 MTU5OTg4bV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy00NjI5ODQyNTY5Mzg1MTU5OTg4bV85 MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBKdW4gMTQsIDIwMTcsIGF0 IDU6MjUgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NaWtlLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Zb3VyIGV4cGxhbmF0 aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1wcm9ibGVtIGlzIGRlcGVuZGVudCB1cG9uIHNpZGUg ZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVuSUQgQ29ubmVjdCB0aGF0IHdlcmUgbm90IGRlc2ln bmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFzIGEgcmVzdWx0LCBJIHNlZSBzZXZlcmFsIGlzc3Vl cyB3aXRoIGl0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im0tNDYy OTg0MjU2OTM4NTE1OTk4OG05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGNhbGxlciBvZg0KIHRo ZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBjZXJ0YWluIHRo YXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tlbi4gQW55IHBhcnR5 IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBoYXMgbm8gd2F5IHRv IHZlcmlmeSBpdHMgcHJvdmVuYW5jZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBo IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjIuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbnkgZnV0dXJlIElE DQogVG9rZW4gZGlzdHJpYnV0aW9uIG1ldGhvZCBuZWVkcyB0byBzb2x2ZSB0aGlzIHByb2JsZW0g YWdhaW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1 OTk4OG05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+My48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4 OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPk5vIG90aGVyIHByb2ZpbGUgb2YgSldUIGNhbiBldmVyDQogdXNlIHRoZSAmcXVvdDtub25j ZeKAnSBjbGFpbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS00NjI5ODQyNTY5 Mzg1MTU5OTg4bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1 MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VGhpcyBpcyBvbmx5IGEgc29sdXRpb24gZm9yIElEDQogVG9rZW5zLiBFdmVyeSBv dGhlciBKV1QgcHJvZmlsZSB0aGF0IGNhcmVzIGFib3V0IGRpc2FtYmlndWF0aW9uIGhhcyB0byBp bnZlbnQgaXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPldlIGtub3cgZnJvbSBleHBlcmllbmNlIHRoYXQgbmFtaW5nIGNv bGxpc2lvbnMgYW5kIHJlcGxheSBhdHRhY2tzIGFyZSBib3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4g V2hhdOKAmXMgYmVpbmcgcHJvcG9zZWQgaXMgYSBzaW1wbGUsIGRlZmVuc2l2ZSBtZWFzdXJlIGFn YWluc3QgdGhlc2Ugcmlza3MuIFlvdSBicm91Z2h0IHVwIEpXVCBsaWJyYXJpZXM6DQogYSBnZW5l cmFsIHNvbHV0aW9uIGFjdHVhbGx5IG1ha2VzIGl0IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJh cmllcyBmb3IgSldUIHBhcnNpbmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291 bGQgaGFuZGxlIGRpc2FtYmlndWF0aW9uIGZvciBhbnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0 aCB0aGUgc3RhdHVzIHF1byBlYWNoIHByb2ZpbGUgd291bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KLS0mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCklkZW50aXR5IFNl cnZpY2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklkLWV2ZW50ICZsdDs8 YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIEp1bmUgMTQsIDIwMTcg YXQgMToxNiBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TWFyaXVzIFNjdXJ0ZXNjdSAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFu LCBBbm5hYmVsbGUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1h em9uLmNvbTwvc3Bhbj48L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssDQogSGVuayBC aXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIu ZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZW5rLmJpcmto b2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3Bh biBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4g Y29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+WW914oCZdmUgaGVhcmQgb2Yg4oCccHJlbWF0dXJlIG9wdGltaXph dGlvbuKAnS4mbmJzcDsgSeKAmWQgY2hhcmFjdGVyaXplIHRoZSBwcm9wb3NhbHMgaW4gdGhpcyB0 aHJlYWQgYXMg4oCccHJlbWF0dXJlIHBlc3NpbWF0aW9u4oCdIOKAkyBtYWtpbmcgdGhpbmdzIHRo YXQgY2FuIGFuZCBzaG91bGQgYmUgc2ltcGxlIGNvbXBsZXgsIHdpdGhvdXQgZGF0YSBzaG93aW5n IHRoZXJl4oCZcw0KIGFueSBuZWVkIHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj5NYW5kYXRvcnkgc29sdXRpb25zIGFyZSBiZWluZyBwcm9wb3NlZCBpbiB0 aGlzIHRocmVhZCB0byBwcm9ibGVtcyB0aGF0IHRoZXJl4oCZcyBubyBldmlkZW5jZSB0aGF0IHdl IGFjdHVhbGx5IGV2ZW4gaGF2ZS4mbmJzcDsgSXTigJlzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hl ZCB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZvciBhIFNFVCB0byBiZSBjb25mdXNlZA0KIGZvciBh biBJRCBUb2tlbiDigJMgc2VlPHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwtMkRh cmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNnMDA0MjguaHRtbCZhbXA7ZD1Ed01HYVEm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3 SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9ZUtMVFFQbVlyVjNUaGZE Ym45MFNDczU1VVJPVFBpbl9sZ2M2UmRyNVhvdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRtbDwvc3Bhbj48L2E+LiZuYnNwOw0KIElm IHBlb3BsZSBoYXZlIGRhdGEgc2hvd2luZyB0aGF0IHRoaXMgaXMgcG9zc2libGUgd2l0aCBzcGVj aWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9rZW5zIG9yIG90aGVyIHJlYWwgSldUIGRlcGxveW1lbnRz LCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZpY3MsIHNvIHRoYXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEg dG8gaW5mb3JtIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5nIGNob2ljZXMgb24gb3VyIHBhcnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBwcm9wb3NlZCDigJxzb2x1 dGlvbnPigJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhl IG5vcm1hbCB3YXksIG9yIHJlcXVpcmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlv dXNseSBzaW1wbGUgdGhpbmdzIHVubmVjZXNzYXJpbHkgY29tcGxleC4mbmJzcDsgWWVzLCB0aGVu IHRoZSByZXN1bHQgaXMgdGhlbg0KIGRpZmZlcmVudCB0aGFuIGEgbm9ybWFsIEpXVCBidXQgYSBj b25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgY3VzdG9tIHBhcnNpbmcgY29kZSB3b3VsZCBoYXZl IHRvIGJlIHVzZWQsIHJhdGhlciB0aGFuIGEgc3RhbmRhcmQgSldUIHBhcnNlci4mbmJzcDsgVGhl IG1vcmUgdW53aWVsZHkgd2UgbWFrZSBpdCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRl dmVsb3BlcnMgYXJlIHRvIGp1c3QgY3JlYXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuJm5i c3A7DQogS2VlcGluZyBpdCBzaW1wbGUgaXMgdGhlIGtleSB0byBhZG9wdGlvbi4mbmJzcDsgU3Rh bmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0aGV5IGFyZSBhY3R1YWxseSB1c2VkLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9Im0tNDYyOTg0 MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWQtZXZlbnQNCiBbPGEgaHJlZj0ibWFp bHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5tYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+XTxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5 Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJpY2hhcmQN CiBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibS00NjI5 ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2Rh eSwgSnVuZSAxMywgMjAxNyA1OjMzIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtLTQ2 Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NYXJp dXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29n bGUuY29tPC9zcGFuPjwvYT4mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86 aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L3NwYW4+ PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4 OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklEIEV2ZW50cyBNYWlsaW5nIExp c3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4 OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIHNvbHV0 aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FY2hvaW5nIE1hcml1c+KAmXMg cXVlc3Rpb246IGNhbiB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG8geW91ciBmaXJz dCBxdWVzdGlvbiwgSSB0aGluayBhIGJldHRlciBhbmFsb2d5IHdvdWxkIGJlIHRoZSBYLjUwOSBL ZXkgVXNhZ2UgZXh0ZW5zaW9uOiBhIG11bHRpLXZhbHVlZCBwcm9wZXJ0eSB0aGF0IGRlY2xhcmVz IHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBKV1QsIGFuZCB0aGF0IGEgcmVjaXBpZW50IG1h eSByZWZlciB0bw0KIHdoZW4gZGV0ZXJtaW5pbmcgd2hldGhlciB0byBhY2NlcHQgYSBKV1QgYmVp bmcgcHJlc2VudGVkIHRvIGl0IGluIHNvbWUgY29udGV4dC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQotLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KQW5uYWJlbGxlIFJpY2hhcmQg QmFja21hbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PHNw YW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ow0KIG9uIGJlaGFs ZiBvZiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0i bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPlR1ZXNkYXksIEp1bmUgMTMsIDIwMTcgYXQgMTE6MDUgQU08YnI+DQo8Yj5Ubzo8c3BhbiBj bGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9iPkhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0Ozxicj4N CjxiPkNjOjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+SUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0Fj Y2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KT24gVHVlLCBKdW4gMTMsIDIwMTcg YXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hv bHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9zcGFuPjwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQpBbmQgYSAybmQgcXVlc3Rpb24uPGJyPg0KPGJyPg0KV2hhdCBzZW1hbnRp Y3Mgd291bGQgJnF1b3Q7dXNhZ2UmcXVvdDsgcHJvdmlkZSB0aGF0IHRoYXQgYXJlIG5vdCBjb3Zl cmVkIHZpYSAmcXVvdDtpbnRlbmQmcXVvdDssICZxdW90O2F1ZGllbmNlJnF1b3Q7LCBhbmQgJnF1 b3Q7c2NvcGUmcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQomcXVvdDth dWQmcXVvdDsgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdldCBjbGllbnQsIGJ1dCBub3Qg dGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0aG9yaXplIHJlc291cmNlIGFj Y2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1cml0eSBldmVudD8pPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCiZxdW90O3Njb3BlJnF1b3Q7IGlzIG5vdCB1c2VkIGJ5IFNFVC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KSSBkb24ndCBrbm93IHdoYXQgZG8geW91IG1lYW4gYnkg JnF1b3Q7aW50ZW5kJnF1b3Q7IChvciBpbnRlbnQpPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8YnI+DQo8YnI+DQpIZW5r PGJyPg0KPGJyPg0KT24gMDYvMTMvMjAxNyAwMTowMSBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyITxi cj4NCjxicj4NCkkgdGhpbmsgdGhlIGFzc3VtcHRpb25zIGluaGVyZW50IGluIDMuOSBhcmUgZmxh d2VkOjxicj4NCjxicj4NCsK3V2UgY2Fu4oCZdCBndWFyYW50ZWUgdGhhdCBldmVyeSB0eXBlIG9m IEpXVCB3aWxsIGhhdmUgYSBtdXR1YWxseSBleGNsdXNpdmUgc2V0IG9mIHZhbGlkIGNsYWltcyBh bmQvb3IgaGVhZGVyIHBhcmFtZXRlcnMsIGFuZCBlbmZvcmNpbmcgdGhpcyByZXF1aXJlcyBhIOKA nGZhaWwgb24gYW4gdW5yZWNvZ25pemVkIGNsYWlt4oCdIGFwcHJvYWNoIHRvIGVuc3VyZSB0aGF0 IEpXVHMgZnJvbSBzb21lIGZ1dHVyZSBzcGVjIGNhbuKAmXQgYmUgbWlzdGFrZW4gZm9yIEpXVHMN CiBmcm9tIGEgY3VycmVudCBzcGVjLjxicj4NCjxicj4NCsK3SXQgaXMgdW5yZWFsaXN0aWMgdG8g ZXhwZWN0IGltcGxlbWVudGVycyB0byBhZGhlcmUgdG8gdGhlIOKAnGRpZmZlcmVudCBrZXlzIGZv ciBkaWZmZXJlbnQga2luZHMgb2YgSldUc+KAnSBydWxlLiBXaGV0aGVyIG1hbmRhdGVkIGJ5IHRo ZSBzcGVjIG9yIG5vdCwgaW1wbGVtZW50ZXJzIHdpbGwgaWdub3JlIHRoaXMgYmVjYXVzZSBtYW5h Z2luZyBvbmUga2V5IGlzIGVhc2llciB0aGFuIG1hbmFnaW5nIE4gZGlmZmVyZW50IGtleXMuPGJy Pg0KPGJyPg0KwrdEaXR0byBmb3Ig4oCcYXVk4oCdIGFuZCDigJxpc3PigJ0gY2xhaW1zLjxicj4N Cjxicj4NCiYjNDM7MSBmb3IgYSDigJx0eXBl4oCdIG9yIOKAnHVzYWdl4oCdIGNsYWltL2hlYWRl ciBwYXJhbWV0ZXIuPGJyPg0KPGJyPg0KLS08c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5 OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbjxicj4NCjxicj4NCklkZW50aXR5IFNlcnZpY2VzPGJyPg0KPGJy Pg0KKkZyb206ICpJZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1l dmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bh bj48L2E+Jmd0Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBKdW5lIDEyLCAyMDE3IGF0IDM6MTggUE08 YnI+DQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNj dUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KKkNjOiAqQWRhbSBEYXdl cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhd2VzQGdvb2dsZS5jb208L3NwYW4+PC9hPiZn dDssICZxdW90O21hdGFrZSwgbm92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bm92QG1hdGFr ZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm5vdkBtYXRh a2UuanA8L3NwYW4+PC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nDQogTGlzdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssICZxdW90O1Bo aWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50 QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQoqU3ViamVjdDogKlJlOiBbSWQtZXZlbnRd IHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQg aXNzdWVyPGJyPg0KPGJyPg0KQWdyZWVkLiBOb3RlIHRoYXQgdGhlcmUgaXMgc3RpbGwgbG90cyBv ZiBkaXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMuOS48YnI+DQo8YnI+DQpPbiBNb24s IEp1biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJt YWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9h PiZndDsmZ3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHRo ZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0pPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICZxdW90OzIuNy4gQ3Jvc3MtSldUIENvbmZ1 c2lvbiZxdW90OyBhbmQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBtaXRpZ2F0aW9uIGlzIGluICZx dW90OzMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2ZSBWYWxpZGF0aW9uIFJ1bGVzIGZvcjxicj4N CiZuYnNwOyAmbmJzcDsgRGlmZmVyZW50IEtpbmRzIG9mIEpXVHMmcXVvdDssIHNwZWNpZmljYWxs eSAmcXVvdDtVc2UgZGlmZmVyZW50IHNldHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IHJlcXVpcmVk IGNsYWltcy4uLiZxdW90OywgJnF1b3Q7VXNlIGRpZmZlcmVudCBrZXlzIGZvciBkaWZmZXJlbnQg a2luZHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IEpXVHMuJnF1b3Q7IGFuZCAmcXVvdDtVc2UgZGlm ZmVyZW50IGlzc3VlcnMgZm9yIGRpZmZlcmVudCBraW5kcyBvZiBKV1RzLiZxdW90Oy48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IEkgc3RpbGwgdGhpbmsgdGhhdCBhICZxdW90O3R5cGUmcXVvdDsg Y2xhaW0gd291bGQgYnJpbmcgYSBsb3Qgb2YgY2xhcml0eSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7 IHNhZmV0eS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE1hcml1czxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBhdCA5OjU5IFBNLCBEaWNrIEhhcmR0 ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48 L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFyb24sIE1pa2UgYW5kIEkganVzdCBwdWJs aXNoZWQgYW4gQkNQIElEIGZvciBKV1Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3NlbGYtMkRpc3N1ZWQuaW5mb18tM0ZwLTNEMTY5MCZhbXA7ZD1Ed01H YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9YTdYdlo1alRidEEy dmpmYUhJTWJ2RU9wU0JCbEJwZHNEa0lUWk1jVUlVUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkw PC9zcGFuPjwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gVGh1 LCBKdW4gOCwgMjAxNyBhdCA5OjAyIFBNIEFkYW0gRGF3ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzph ZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmFkYXdlc0Bnb29nbGUuY29tPC9zcGFuPjwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNAZ29vZ2xlLmNv bTwvc3Bhbj48L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSB3YXMgaW5pdGlhbGx5IGEgZmFuIG9mIGtlZXBpbmcg U0VUUyB0byBiZSB2ZXJ5IHNpbWlsYXIgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBpZCB0b2tlbnMgYnV0IEkgbm93IHRoaW5rIHRoaXMgaXMgYSBiZXR0 ZXIgcGxhbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDY6NTYgUE0gbWF0YWtlLCBub3YgJmx0OzxhIGhy ZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+bm92QG1hdGFrZS5qcDwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bm92 QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm5v dkBtYXRha2UuanA8L3NwYW4+PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxIGVz cGVjaWFsbHkgZm9yICZxdW90O3R5cGUmcXVvdDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMTctMDYtMDkgMTA6MzIg R01UJiM0MzswOTowMCBQaGlsIEh1bnQgKElETSk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyZndDs6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7MTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaGls PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgT24gSnVuIDgsIDIwMTcs IGF0IDY6MjggUE0sIE1hcml1cyBTY3VydGVzY3U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhy ZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0 OyB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7IFRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcHJvcG9zYWxzIG9uIGhvdyB0bzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBkaXN0aW5ndWlzaCBTRVRzIGZyb20gSWQgVG9rZW5zIGFuZCBBY2Nlc3Mg VG9rZW5zIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1Y2ggYSB3YXkgdGhhdCBuYWl2ZSBpbXBsZW1l bnRhdGlvbnMgd2lsbCBub3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uZnVzZSBvbmUgZm9yIHRoZSBv dGhlciBhbmQgb3BlbiB1cCBzZWN1cml0eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2dWxuZXJhYmlsaXRp ZXMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBUaGVyZSBpcyBhbHNvIGFub3RoZXIgaW1wb3J0YW50IHJlcXVpcmVtZW50OiB0aGU8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgU0VUIGlzc3VlciBpbiBzb21lIGNhc2VzIG11c3QgYmUgZGlmZmVyZW50 IGZyb20gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N1YiZxdW90OyBpc3N1ZXIuIFRoaXMg aXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGFu IElkUC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IFdpdGggdGhlc2UgcmVxdWlyZW1lbnRzIGluIG1pbmQgSSBwcm9wb3NlIHRoZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBmb2xsb3dpbmc6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgLSBi b3RoICZxdW90O3N1YiZxdW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7IHRvIGJlIGRlZmluZWQgYXQg dGhlIGV2ZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxldmVsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgLSAmcXVvdDtpc3MmcXVvdDsgYXQgZXZlbnQgbGV2ZWwgYW5kIGF0IHRvcCBTRVQgbGV2 ZWwgY2FuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlIGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDtzdWImcXVvdDsgYXQgZXZlbnQg bGV2ZWwgY2FuIGJlIGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhY3Jvc3MgZXZlbnRzIGlu IHRoZSBzYW1lIFNFVDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7c3ViJnF1 b3Q7IHNob3VsZCBOT1QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIFNFVDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBsZXZlbCAodGhpcyBzb2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGU8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c2hvdWxkJnF1b3Q7IGFuZCBub3QgJnF1b3Q7bXVzdCZxdW90 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsgVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQgcHJvZmlsZXMgdGhhdDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwgY2xh aW1zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlbGF0ZWQgdG8gc3ViIChsaWtlIGVtYWlsIG9yIHBob25l X251bWJlcikgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNpbmNlIGFsbCB0aGVzZSBjbGFpbXMgd2ls bCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgd2lsbCBiZSBu byBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFub3RoZXIgcHJvcG9zYWwgKHdoaWNoIEkgc3Vw cG9ydGVkKSB3YXMgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGEgY29tcG9zaXRlICZxdW90 O2F1ZCZxdW90OyBjbGFpbS4gVGhpcyBpcyBub3Qgc29sdmluZzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0 aGUgcmVxdWlyZW1lbnQgZm9yIGEgZGlzdGluY3QmbmJzcDsgU0VUIGlzc3Vlci4gQWxzbyw8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgaGF2aW5nIHRoZSBzYW1lIGNsYWltIG5hbWUgaGF2aW5nIGRpZmZlcmVu dCBzeW50YXg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gZGlmZmVyZW50IHRva2VuIHR5cGVzIGNvdWxk IGxlYWQgdG8gY29uZnVzaW9uLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsgQW5kIHlldCBhbm90aGVyIHByb3Bvc2FsIHdhcyB0byBpbnRy b2R1Y2UgYSBuZXc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2xhaW0gZm9yIEpXVHMgdGhhdCBkZWZpbmVz IGEgJnF1b3Q7dHlwZSZxdW90Oy4gVGhpcyBpcyBub3Q8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJhY3Rp Y2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3Q8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBidXQgSSB0aGluazxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNob3VsZCBz ZXJpb3VzbHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uc2lkZXIuPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaG91Z2h0cz88YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IE1hcml1czxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgSWQt ZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OzxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQt ZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZt aVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZK TGh4V0kmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209Sm11dXRCeDREQVBwNzRB VUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZhbXA7cz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9W cG44OFlLT0NkMG14UFFGSkxoeFdJJmFtcDtlPTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxz cGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gY2xhc3M9Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00 NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdK UEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklU WDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3Bh biBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGll dGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5 ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5Zzdv TVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bh bj48L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgLS08c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQWRhbSBEYXdlcyB8IFNyLiBQcm9kdWN0IE1hbmFnZXIgfDxhIGhyZWY9Im1haWx0 bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmFkYXdlc0Bnb29nbGUuY29tPC9zcGFuPjwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGF3 ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmFkYXdlc0Bnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7IHw8YSBocmVmPSJ0ZWw6JTJCMSUyMDY1 MC0yMTQtMjQxMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiYj NDM7MSA2NTAtMjE0LTI0MTA8L3NwYW4+PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJ0ZWw6JTI4NjUwJTI5JTIwMjE0LTI0MTAi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50ZWw6KDY1MCklMjAy MTQtMjQxMDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS00NjI5ODQyNTY5Mzg1MTU5 OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJ VFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhD c0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3 b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3Nw YW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLTxzcGFuIGNs YXNzPSJtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3Vic2NyaWJlIHRvIHRoZSBI QVJEVFdBUkUgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3 NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9aTc1VXc4YWVoWXZscElaTkw3TnhxR3hoaDFU T3JRT1VYMlhNWUJlclY4MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5odHRwOi8vaGFyZHR3YXJlLmNvbS88L3NwYW4+PC9hPiZndDsNCiBtYWlsIGxp c3QgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGVhcm4gYWJvdXQgcHJvamVj dHMgSSBhbSB3b3JraW5nIG9uITxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tPHNwYW4gY2xhc3M9 Im0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4NCjxicj4NClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFICZsdDs8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJl LmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRw a0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19s TElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFt cDtzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJWODAmYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL2hhcmR0d2Fy ZS5jb20vPC9zcGFuPjwvYT4mZ3Q7DQogbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3Rz IEkgYW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm YW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1V c2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pz c0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5Zzdv TVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtk PUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209 VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6 c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTEx NWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7 ZT08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQt ZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPklkLWV2ZW50IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5J ZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50 QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E967B191C08B4C96927E8A22E0673AF9amazoncom_-- From nobody Wed Jun 21 16:39:39 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B612426E for ; Wed, 21 Jun 2017 16:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYc45UEq3q_d for ; Wed, 21 Jun 2017 16:39:32 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049B9126D74 for ; Wed, 21 Jun 2017 16:39:31 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5LNdQvx019410 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Jun 2017 23:39:26 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5LNdPJS001727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jun 2017 23:39:26 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5LNdKpW027863; Wed, 21 Jun 2017 23:39:21 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jun 2017 16:39:18 -0700 From: Phil Hunt Message-Id: <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F15F2A85-E5AD-42D2-843C-94A5196D10A5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 21 Jun 2017 16:39:14 -0700 In-Reply-To: Cc: Marius Scurtescu , John Bradley , Henk Birkholz , Justin Richer , Yaron Sheffer , Mike Jones , ID Events Mailing List To: "Richard Backman, Annabelle" References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 23:39:37 -0000 --Apple-Mail=_F15F2A85-E5AD-42D2-843C-94A5196D10A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So I understand what is being proposed is: If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, = and the issuer of the subject is identical to the issuer for the event, = then =E2=80=9Csub=E2=80=9D may be used at the top level. Otherwise, the = subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims = required to uniquely identify the subject MUST be contained in the event = payload. For example, an ip address of 1.2.3.4 might be represented in a = =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. = =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4" A SCIM resource URI of = https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might be = identified in the event payload as: = =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a24= 2bd3859c82c4=E2=80=9D A Connect Logout event from an OP uses the top level sub claim and = depends on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND = the subject. This means that no party may issue logout events on behalf = of the OP. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle = wrote: >=20 > Fair point. If we do not intend to support multiple profiles within a = single SET, then I=E2=80=99m less concerned about leaving sub semantics = up to the profiles. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Marius Scurtescu > Date: Wednesday, June 21, 2017 at 2:58 PM > To: "Richard Backman, Annabelle" > Cc: "Phil Hunt (IDM)" , John Bradley = , Henk Birkholz , = Justin Richer , Yaron Sheffer , = Michael Jones , ID Events Mailing List = > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Example for multiple events within same profile: IdP account is = disabled (because of hijacking), this can lead to two events: > 1. "account-disabled" > 2. "sessions-revoked" >=20 > Marius > =20 > On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle = > wrote: >> The spec says that the events claim SHOULD NOT be used to express = multiple logical events. If it=E2=80=99s also not used to express events = from different profiles that correspond to the same logical event (e.g. = an OIDC backchannel logout event alongside a hypothetical RISC logout = event), then I=E2=80=99m not sure what use case that leaves for multiple = events in one SET. >> =20 >> --=20 >> Annabelle Richard Backman >> Identity Services >> =20 >> =20 >> From: Id-event > on behalf of "Phil Hunt (IDM)" = > >> Date: Wednesday, June 21, 2017 at 2:12 PM >> To: John Bradley > >> Cc: "Richard Backman, Annabelle" >, Henk Birkholz = >, Justin Richer = >, Marius Scurtescu = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > >>=20 >> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >> =20 >> Separate or combined may be evolving. Mike wants to keep the current = backchannel logout very narrowly scoped. He suggested risc define its = own duplicate definitions and meanings.=20 >> =20 >> That leads me to believe we will have multi-type events in practice. >> =20 >> Session cancellation can occur for many reasons. One of the = differentiators we had tried to make was an assumption that user = initiated events would be part of connect. Risk would cover variations = that drive off of risk calculations like password reset.=20 >> =20 >> There are also signout events at rp's to let the OP know. These are = not commands but notification that a resource session is cancelled. IOW = single sign out not expected.=20 >>=20 >> Phil >>=20 >> On Jun 21, 2017, at 1:58 PM, John Bradley > wrote: >>=20 >>> I thought we decided that we are only allowing set messages form the = same family that agree on top level claims. >>> =20 >>> Otherwise there can be no top level claims and we are really = defining a alternative format to JWT in some ways. >>> =20 >>> John B. >>> =20 >>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle = > wrote: >>>> =20 >>>> I agree with John that the JWT type confusion problem and the SET = sub problem can and should be discussed separately. The secevents WG is = probably not the right setting to discuss the former. >>>> =20 >>>> My concern with the sub claim is that two profiles may dictate = conflicting semantics (e.g. Profile A says it=E2=80=99s a phone number, = Profile B says it=E2=80=99s an email address). If these profiles don=E2=80= =99t provide an alternate way to declare subject of their events, then = they cannot be present within the same token. This incompatibility trap = seems like something that could be easily missed by groups profiling = SET. >>>> =20 >>>> --=20 >>>> Annabelle Richard Backman >>>> Identity Services >>>> =20 >>>> =20 >>>> From: John Bradley > >>>> Date: Wednesday, June 21, 2017 at 1:39 PM >>>> To: Yaron Sheffer > >>>> Cc: Justin Richer >, = Marius Scurtescu >, = Annabelle Richard >, = Phil Hunt >, Michael = Jones >, ID Events Mailing List = >, Henk Birkholz = > >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>>> =20 >>>> In the envelope typ is a media/mime type. Registering = application/idt+jwt if we register jwt as a structured name sufix. =20 >>>> =20 >>>> Using the cty is also possible. I need to think about what is = better but we can agree on a convention. >>>> =20 >>>> Not everything is going to be a set token like not every JWS is a = JWT. >>>> =20 >>>> If we are going to define processing rules to stop collisions and = confusion around JWT for different purposes, we should just start using = the typ parameter based on the existing spec. >>>> =20 >>>> In general content sniffing if there is more than one option = eventually gets you into trouble. >>>> =20 >>>> I am not convinced that forcing there to be no sub at the top level = is a good idea. =20 >>>> =20 >>>> It is not the way we should differentiate between SET and = id_tokens. >>>> =20 >>>> If sub is not allowed at the top level people will do non SET JWT = for things where the subject is scoped to the iss of the token. >>>> =20 >>>> I think defining sub to be part of the event for cases where the = sub is scoped differently from the issuer of the token is fine, but = should not be required for all event types. >>>> =20 >>>> I think we should solve the confusion issue separately from the sub = issue. >>>> =20 >>>> Sorry I am at CIS so trying to catch up on lists. >>>> =20 >>>> John B. >>>> =20 >>>>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer > wrote: >>>>> =20 >>>>> So to summarize what I'm seeing on this thread: >>>>> Everybody agrees with Marius's short-term solution, specific rules = for "sub" and "iss" that can be defined in the SET spec. >>>>> Almost everybody agrees on a long-term "usage" claim ("type" is = taken) that should be defined elsewhere, e.g. in the JWT BCP. >>>>> Did I miss anything? >>>>> By the way, if we do add a "usage" claim, we need to also use it = in the SET document before it is published. >>>>> Thanks, >>>>> Yaron >>>>> =20 >>>>> On 15/06/17 22:08, Justin Richer wrote: >>>>>> +1 to this as well.=20 >>>>>> =20 >>>>>> =E2=80=94 Justin >>>>>> =20 >>>>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu = > wrote: >>>>>>> =20 >>>>>>> +1 to what Annabelle said.=20 >>>>>>> =20 >>>>>>> Also, Mike you are missing the other requirement, for RPs to = send events to an IdP. The iss+sub pair at the top level is broken in = this case. >>>>>>>=20 >>>>>>> Marius >>>>>>> =20 >>>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) = > wrote: >>>>>>>> +1 >>>>>>>> =20 >>>>>>>> Phil >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >>>>>>>>> Mike, >>>>>>>>> =20 >>>>>>>>> Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with it: >>>>>>>>> 1. The caller of the Token Endpoint is the only party = that can be certain that a nonce-less ID Token is really an ID Token. = Any party that the caller passes the ID Token off to has no way to = verify its provenance. >>>>>>>>>=20 >>>>>>>>> 2. Any future ID Token distribution method needs to = solve this problem again. >>>>>>>>>=20 >>>>>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D= claim. >>>>>>>>>=20 >>>>>>>>> 4. This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem. >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> We know from experience that naming collisions and replay = attacks are both things that happen. What=E2=80=99s being proposed is a = simple, defensive measure against these risks. You brought up JWT = libraries: a general solution actually makes it easier to use common = libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library = could handle disambiguation for any JWT profile, whereas with the status = quo each profile would require unique logic. >>>>>>>>> =20 >>>>>>>>> --=20 >>>>>>>>> Annabelle Richard Backman >>>>>>>>> Identity Services >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> From: Id-event > on behalf of Mike Jones = > >>>>>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>>>>> To: Marius Scurtescu > >>>>>>>>> Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > >>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>>>>> =20 >>>>>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D= . I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprema= ture pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >>>>>>>>> =20 >>>>>>>>> Mandatory solutions are being proposed in this thread to = problems that there=E2=80=99s no evidence that we actually even have. = It=E2=80=99s already been established that it=E2=80=99s impossible for a = SET to be confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >>>>>>>>> =20 >>>>>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting = the use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type = claim, would make previously simple things unnecessarily complex. Yes, = then the result is then different than a normal JWT but a consequence of = this is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. >>>>>>>>> =20 >>>>>>>>> -- Mike >>>>>>>>> =20 >>>>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle >>>>>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>>>>> To: Marius Scurtescu >; Henk Birkholz = > >>>>>>>>> Cc: ID Events Mailing List > >>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>>>>> =20 >>>>>>>>> Echoing Marius=E2=80=99s question: can you explain what you = mean by =E2=80=9Cintend=E2=80=9D? >>>>>>>>> =20 >>>>>>>>> To your first question, I think a better analogy would be the = X.509 Key Usage extension: a multi-valued property that declares the = intended purpose of the JWT, and that a recipient may refer to when = determining whether to accept a JWT being presented to it in some = context. >>>>>>>>> =20 >>>>>>>>> --=20 >>>>>>>>> Annabelle Richard Backman >>>>>>>>> Identity Services >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> From: Id-event > on behalf of Marius Scurtescu = > >>>>>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>>>>> To: Henk Birkholz > >>>>>>>>> Cc: ID Events Mailing List > >>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>>>>> =20 >>>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >>>>>>>>>> And a 2nd question. >>>>>>>>>>=20 >>>>>>>>>> What semantics would "usage" provide that that are not = covered via "intend", "audience", and "scope"? >>>>>>>>> =20 >>>>>>>>> "aud" (audience) specifies the target client, but not the = intended usage (access token to authorize resource access or SET to = communicate a security event?) >>>>>>>>> =20 >>>>>>>>> "scope" is not used by SET. >>>>>>>>> =20 >>>>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Henk >>>>>>>>>>=20 >>>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>=20 >>>>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>>>=20 >>>>>>>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will = have a mutually exclusive set of valid claims and/or header parameters, = and enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80= =9D approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >>>>>>>>>>>=20 >>>>>>>>>>> =C2=B7It is unrealistic to expect implementers to adhere to = the =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >>>>>>>>>>>=20 >>>>>>>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D= claims. >>>>>>>>>>>=20 >>>>>>>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>>=20 >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>=20 >>>>>>>>>>> Identity Services >>>>>>>>>>>=20 >>>>>>>>>>> *From: *Id-event > on behalf of Dick Hardt = > >>>>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>>>> *To: *Marius Scurtescu > >>>>>>>>>>> *Cc: *Adam Dawes >, "matake, nov" >, ID Events Mailing List >, "Phil Hunt (IDM)" > >>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer >>>>>>>>>>>=20 >>>>>>>>>>> Agreed. Note that there is still lots of discussion on what = should be in 3.9. >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = >> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>>>=20 >>>>>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" and = the >>>>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive Validation = Rules for >>>>>>>>>>> Different Kinds of JWTs", specifically "Use different = sets of >>>>>>>>>>> required claims...", "Use different keys for different = kinds of >>>>>>>>>>> JWTs." and "Use different issuers for different kinds of = JWTs.". >>>>>>>>>>>=20 >>>>>>>>>>> I still think that a "type" claim would bring a lot of = clarity and >>>>>>>>>>> safety. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Marius >>>>>>>>>>>=20 >>>>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt = >>>>>>>>>>> >> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>>>> http://self-issued.info/?p=3D1690 = >>>>>>>>>>>=20 >>>>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes = >>>>>>>>>>> >> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I was initially a fan of keeping SETS to be very = similar to >>>>>>>>>>> id tokens but I now think this is a better plan. >>>>>>>>>>>=20 >>>>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov = >>>>>>>>>>> >> = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> +1 especially for "type" >>>>>>>>>>>=20 >>>>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>>>> >>: >>>>>>>>>>>=20 >>>>>>>>>>> +1 >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius = Scurtescu >>>>>>>>>>> >>>>>>>>>>> >> wrote: >>>>>>>>>>> > >>>>>>>>>>> > There were a couple of proposals on = how to >>>>>>>>>>> distinguish SETs from Id Tokens and = Access Tokens in >>>>>>>>>>> such a way that naive implementations = will not >>>>>>>>>>> confuse one for the other and open up = security >>>>>>>>>>> vulnerabilities. >>>>>>>>>>> > >>>>>>>>>>> > There is also another important = requirement: the >>>>>>>>>>> SET issuer in some cases must be = different from the >>>>>>>>>>> "sub" issuer. This is the case of an RP = sending SETs >>>>>>>>>>> to an IdP. >>>>>>>>>>> > >>>>>>>>>>> > With these requirements in mind I = propose the >>>>>>>>>>> following: >>>>>>>>>>> > - both "sub" and "iss" to be defined = at the event >>>>>>>>>>> level >>>>>>>>>>> > - "iss" at event level and at top SET = level can >>>>>>>>>>> be different >>>>>>>>>>> > - "iss" and "sub" at event level can = be different >>>>>>>>>>> across events in the same SET >>>>>>>>>>> > - "sub" should NOT be present at the = top SET >>>>>>>>>>> level (this solves the disambiguation), = please note >>>>>>>>>>> "should" and not "must" >>>>>>>>>>> > >>>>>>>>>>> > This solution also allows different = profiles that >>>>>>>>>>> define event types to define additional = claims >>>>>>>>>>> related to sub (like email or = phone_number) and >>>>>>>>>>> since all these claims will be at the = event level >>>>>>>>>>> there will be no collisions or = ambiguity. >>>>>>>>>>> > >>>>>>>>>>> > Another proposal (which I supported) = was to >>>>>>>>>>> define a composite "aud" claim. This is = not solving >>>>>>>>>>> the requirement for a distinct SET = issuer. Also, >>>>>>>>>>> having the same claim name having = different syntax >>>>>>>>>>> in different token types could lead to = confusion. >>>>>>>>>>> > >>>>>>>>>>> > And yet another proposal was to = introduce a new >>>>>>>>>>> claim for JWTs that defines a "type". = This is not >>>>>>>>>>> practical in the short term, and it also = is not >>>>>>>>>>> solving the distinct issuer requirement, = but I think >>>>>>>>>>> this is something the JWT group should = seriously >>>>>>>>>>> consider. >>>>>>>>>>> > >>>>>>>>>>> > Thoughts? >>>>>>>>>>> > >>>>>>>>>>> > Marius >>>>>>>>>>>=20 >>>>>>>>>>> > = _______________________________________________ >>>>>>>>>>> > Id-event mailing list >>>>>>>>>>> > Id-event@ietf.org = > >>>>>>>>>>> > >>>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >>>>>>>>>>>=20 >>>>>>>>>>> = _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>>> = https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>=20 >>>>>>>>>>> = _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>>> = https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> Adam Dawes | Sr. Product Manager = |adawes@google.com >>>>>>>>>>> > |+1 650-214-2410 >>>>>>>>>>> > >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> Subscribe to the HARDTWARE > mail list to >>>>>>>>>>> learn about projects I am working on! >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>>=20 >>>>>>>>>>> Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event = =20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>> =20 >>>=20 >>> =20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = > =20 --Apple-Mail=_F15F2A85-E5AD-42D2-843C-94A5196D10A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
So I understand what is being proposed = is:

If the event type uses =E2=80=9Csub=E2=80=9D= to identify its subject, and the issuer of the subject is identical to = the issuer for the event, then =E2=80=9Csub=E2=80=9D may be used at the = top level. Otherwise, the subject of an event (e.g. =E2=80=9Csub=E2=80=9D)= and any other claims required to uniquely identify the subject MUST be = contained in the event payload.

For example, an ip address of 1.2.3.4 = might be represented in a =E2=80=9Cipaddress=E2=80=9D claim defined in = the event payload. =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4= might be identified in the event payload as: =E2=80=9Csub=E2=80=9D:"<= a href=3D"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4"= = class=3D"">https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4= =E2=80=9D

A = Connect Logout event from an OP uses the top level sub claim and depends = on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the = subject. This means that no party may issue logout events on behalf of = the OP.


Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

Fair point. If we do not intend to support multiple profiles = within a single SET, then I=E2=80=99m less concerned about leaving sub = semantics up to the profiles.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Marius Scurtescu = <mscurtescu@google.com>
Date: Wednesday, June 21, = 2017 at 2:58 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: "Phil= Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, = Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
Example for multiple = events within same profile: IdP account is disabled (because of = hijacking), this can lead to two events:
1. = "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the = events claim SHOULD NOT be used to express multiple logical events. If = it=E2=80=99s also not used to express events from different profiles = that correspond to the same logical event (e.g. an OIDC backchannel = logout event alongside a hypothetical RISC logout event), then I=E2=80=99m= not sure what use case that leaves for multiple events in one = SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt = (IDM)" <phil.hunt@oracle.com>
Date: Wednesday, June 21, = 2017 at 2:12 PM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "Richard Backman, = Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, = Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>

Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
Separate or combined may be evolving. = Mike wants to keep the current backchannel logout very narrowly scoped. = He suggested risc define its own duplicate definitions and = meanings. 
 
That leads me to believe we will have = multi-type events in practice.
 
Session cancellation can occur for many = reasons. One of the differentiators we had tried to make was an = assumption that user initiated events would be part of connect. Risk = would cover variations that drive off of risk calculations like password = reset. 
 
There are also signout events at rp's to = let the OP know. These are not commands but notification that a resource = session is cancelled. IOW single sign out not expected. 

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley = <ve7jtb@ve7jtb.com>= wrote:

I thought we decided that we are only = allowing set messages form the same family that agree on top level = claims.
 
Otherwise there can = be no top level claims and we are really defining a alternative format = to JWT in some ways.
 
John B.
 
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:
 
I agree with John that the JWT type confusion = problem and the SET sub problem can and should be discussed separately. = The secevents WG is probably not the right setting to discuss the = former.
 
My concern with the sub claim is that two = profiles may dictate conflicting semantics (e.g. Profile A says it=E2=80=99= s a phone number, Profile B says it=E2=80=99s an email address). If = these profiles don=E2=80=99t provide an alternate way to declare subject = of their events, then they cannot be present within the same token. This = incompatibility trap seems like something that could be easily missed by = groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: <= /b>John = Bradley <ve7jtb@ve7jtb.com>
Date: Wedn= esday, June 21, 2017 at 1:39 PM
To: Yaro= n Sheffer <yaronf.ietf@gmail.com>
Cc: Just= in Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
In the envelope typ is a media/mime type.  Registering = application/idt+jwt if we register jwt as a structured name sufix. =  
 
Using the cty is also possible. =   I need to think about what is better but we can agree on a = convention.
 
Not everything = is going to be a set token like not every JWS is a JWT.
 
If we are going = to define processing rules to stop collisions and confusion around JWT = for different purposes, we should just start using the typ parameter = based on the existing spec.
 
In general = content sniffing if there is more than one option eventually gets you = into trouble.
 
I am not convinced that forcing = there to be no sub at the top level is a good idea.  
 
It is not the = way we should differentiate between SET and id_tokens.
 
If sub is not = allowed at the top level people will do non SET JWT for things where the = subject is scoped to the iss of the token.
 
I think defining = sub to be part of the event for cases where the sub is scoped = differently from the issuer of the token is fine, but should not be = required for all event types.
 
I think we = should solve the confusion issue separately from the sub issue.
 
Sorry I am at = CIS so trying to catch up on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 PM, Yaron = Sheffer <yaronf.ietf@gmail.com> = wrote:
 
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's = short-term solution, specific rules for "sub" and "iss" that can be = defined in the SET spec.
Almost everybody agrees on a long-term "usage" claim ("type" = is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" = claim, we need to also use it in the SET document before it is = published.
Thanks,
    Yaron
 
On 15/06/17 = 22:08, Justin Richer wrote:
+1 to this as = well. 
 
 =E2=80=94 = Justin
 
On Jun 15, 2017, = at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what Annabelle said. 
 
Also, Mike you = are missing the other requirement, for RPs to send events to an IdP. The = iss+sub pair at the top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
 
Phil

 

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = <richanna@amazon.com> = wrote:
Mike,
 
Your explanation for = why this is a non-problem is dependent upon side effects of elements of = OpenID Connect that were not designed to solve this issue. As a result, = I see several issues with it:

1.       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance.

2.       <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">Any future ID Token distribution method needs to solve this = problem again.

3.      <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">No other profile of JWT can ever use the "nonce=E2=80=9D = claim.

4.      <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">This is only a solution for ID Tokens. Every other JWT = profile that cares about disambiguation has to invent its own solution = to the problem.

 
We know from = experience that naming collisions and replay attacks are both things = that happen. What=E2=80=99s being proposed is a simple, defensive = measure against these risks. You brought up JWT libraries: a general = solution actually makes it easier to use common libraries for JWT = parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: <= /b>Id-event = <id-event-bounces@ietf.org> on behalf of Mike = Jones <Michael.Jones@microsoft.com>
Date: Wedn= esday, June 14, 2017 at 1:16 PM
To: Mari= us Scurtescu <mscurtescu@google.com>
Cc: "Ric= hard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List = <id-event@ietf.org>, Henk Birkholz = <henk.birkholz@sit.fraunhofer.de>
Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
You=E2=80=99ve heard of =E2=80=9Cpremature = optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in = this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making = things that can and should be simple complex, without data showing = there=E2=80=99s any need to do so.
 
Mandatory solutions are being proposed in = this thread to problems that there=E2=80=99s no evidence that we = actually even have.  It=E2=80=99s already been established that = it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93= see https://www.ietf.org/mail-archive/web/id-event/current/msg00428= .html.  If people have data showing that this is = possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part.
 
The proposed =E2=80=9Csolutions=E2=80=9D, = such as prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, = or requiring a type claim, would make previously simple things = unnecessarily complex.  Yes, then the result is then different than = a normal JWT but a consequence of this is that custom parsing code would = have to be used, rather than a standard JWT parser.  The more = unwieldy we make it to use SETs, the more likely developers are to just = create their own data structures.  Keeping it simple is the key to = adoption.  Standards are only useful if they are actually = used.
 
          &nb= sp;            = ;            &= nbsp;            = -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Rich= ard Backman, Annabelle
Sent: Tuesday,= June 13, 2017 5:33 PM
To: Marius = Scurtescu <mscurtescu@google.com>; = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID = Events Mailing List <id-event@ietf.org>
Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Echoing Marius=E2=80=99= s question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?
 
To your first question, I think a better analogy = would be the X.509 Key Usage extension: a multi-valued property that = declares the intended purpose of the JWT, and that a recipient may refer = to when determining whether to accept a JWT being presented to it in = some context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: <= /b>Id-event = <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date: Tues= day, June 13, 2017 at 11:05 AM
To: Henk= Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID = Events Mailing List <id-event@ietf.org>
Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
On Tue, Jun 13, 2017 at 2:11 AM, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.
What semantics would "usage" provide that that are not = covered via "intend", "audience", and "scope"?
 
"aud" (audience) specifies the target client, but not the = intended usage (access token to authorize resource access or SET to = communicate a security event?)
 
"scope" is not used by SET.
 
I don't know what do you mean by = "intend" (or intent)?
 
 

Henk

On 06/13/2017 01:01 AM, = Richard Backman, Annabelle wrote:
Thanks for putting this = together!

I think the assumptions inherent = in 3.9 are flawed:

=C2=B7We can=E2=80=99t = guarantee that every type of JWT will have a mutually exclusive set of = valid claims and/or header parameters, and enforcing this requires a = =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that = JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a = current spec.

=C2=B7It is unrealistic to = expect implementers to adhere to the =E2=80=9Cdifferent keys for = different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec or = not, implementers will ignore this because managing one key is easier = than managing N different keys.

=C2=B7Ditto = for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusag= e=E2=80=9D claim/header parameter.

-- 

Annabelle Richard Backman

Identity Services

*From: = *Id-event <id-event-bounces@ietf.org> on behalf of Dick = Hardt <dick.hardt@gmail.com>*Date: *Monday, June 12, 2017 at 3:18 PM
*To: = *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam = Dawes <adawes@google.com>, = "matake, nov" <nov@matake.jp>, ID = Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

Agreed. = Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius = Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, = very good timing :-)

    The = issue is described by "2.7. Cross-JWT Confusion" and the
    mitigation is in "3.9. Use Mutually Exclusive = Validation Rules for
    Different Kinds of = JWTs", specifically "Use different sets of
    = required claims...", "Use different keys for different kinds of
    JWTs." and "Use different issuers for different = kinds of JWTs.".

    I still = think that a "type" claim would bring a lot of clarity and
    safety.


    Marius

  =   On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
  =   <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I = just published an BCP ID for JWT
      =   http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM = Adam Dawes <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I = was initially a fan of keeping SETS to be very similar to
            id tokens but I now = think this is a better plan.

    =         On Thu, Jun 8, 2017 at 6:56 PM matake, nov = <nov@matake.jp
    =         <mailto:nov@matake.jp>> wrote:

                +1 = especially for "type"

      =           2017-06-09 10:32 GMT+09:00 Phil Hunt = (IDM)
              =   <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

            =         +1

  =                   Phil


        =              > On Jun 8, 2017, at = 6:28 PM, Marius Scurtescu
        =             <mscurtescu@google.com
                =     <mailto:mscurtescu@google.com>> wrote:
                =      >
        =              > There were a couple = of proposals on how to
          =           distinguish SETs from Id Tokens and = Access Tokens in
            =         such a way that naive implementations will = not
              =       confuse one for the other and open up security
                =     vulnerabilities.
        =              >
  =                   =  > There is also another important requirement: the
                =     SET issuer in some cases must be different from the
                =     "sub" issuer. This is the case of an RP sending SETs
                =     to an IdP.
        =              >
  =                   =  > With these requirements in mind I propose the
                =     following:
        =              > - both "sub" and = "iss" to be defined at the event
      =               level
                =      > - "iss" at event level and at top SET level = can
              =       be different
      =                > - "iss" and = "sub" at event level can be different
      =               across events in the = same SET
              =        > - "sub" should NOT be present at the top = SET
              =       level (this solves the disambiguation), please = note
              =       "should" and not "must"
    =                  >
                =      > This solution also allows different profiles = that
              =       define event types to define additional claims
                =     related to sub (like email or phone_number) and
                =     since all these claims will be at the event level
                =     there will be no collisions or ambiguity.
                =      >
        =              > Another proposal = (which I supported) was to
        =             define a composite "aud" = claim. This is not solving
        =             the requirement for a = distinct  SET issuer. Also,
      =               having the same claim = name having different syntax
        =             in different token types could = lead to confusion.
          =            >
  =                   =  > And yet another proposal was to introduce a new
                =     claim for JWTs that defines a "type". This is not
                =     practical in the short term, and it also is not
                =     solving the distinct issuer requirement, but I think
                =     this is something the JWT group should seriously
                =     consider.
          =            >
  =                   =  > Thoughts?
          =            >
  =                   =  > Marius

      =                > = _______________________________________________
  =                   =  > Id-event mailing list

      =                > Id-event@ietf.org <mail= to:Id-event@ietf.org>
  =                   =  >
            =         https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6= Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                =     _______________________________________________
                =     Id-event mailing list
      =               Id-event@ietf.org <mail= to:Id-event@ietf.org>
  =                   https://www.ietf.org/mailman/listinfo/id-event

            =     _______________________________________________
                = Id-event mailing list
          =       Id-event@ietf.org <mail= to:Id-event@ietf.org>
  =               https://www.ietf.org/mailman/listinfo/id-event

            = -- 
            Adam Dawes | Sr. = Product Manager |adawes@google.com
            <mailto:adawes@google.com> |+1 650-214-2410
  =           <tel:(650)%20214-2410>

            = _______________________________________________
  =           Id-event mailing list
            Id-event@ietf.org <mail= to:Id-event@ietf.org>
  =           https://www.ietf.org/mailman/listinfo/id-event

        -- 
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working = on!



-- 

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about = projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssK= FZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D
<= div class=3D"">
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 




_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 

= --Apple-Mail=_F15F2A85-E5AD-42D2-843C-94A5196D10A5-- From nobody Wed Jun 21 16:46:09 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11912426E for ; Wed, 21 Jun 2017 16:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-JcxEC0Y6Dt for ; Wed, 21 Jun 2017 16:46:00 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0103.outbound.protection.outlook.com [104.47.36.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C55B1200CF for ; Wed, 21 Jun 2017 16:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7eg2TsJ2Sf9uIIcaiLlVHcP/7/qyhdjThdyHQd62xfg=; b=Ndyrz15zISyGn96xtg5huUz8r8EV6R4QDfHkQHbuiq9bX54/fZ2fGMiHLU6hLOqqTH3kC0okXA1ZPFICrP8/s9HBUL+JtThISpkZY4UGU6M38LbgAXs9DvxFRupLB6RpLVApzbzlzoVepgrV0gxm1N9FEDQUox9TPZCSaeZCciw= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 21 Jun 2017 23:45:58 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.000; Wed, 21 Jun 2017 23:45:58 +0000 From: Mike Jones To: Phil Hunt , "Richard Backman, Annabelle" CC: Marius Scurtescu , John Bradley , Henk Birkholz , "Justin Richer" , Yaron Sheffer , "ID Events Mailing List" Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAZHxQCAAAQVgIAAAU6AgAAD8YCAAAu+gIAAARyAgAAK8YCAABEWAIAAAeGL Date: Wed, 21 Jun 2017 23:45:57 +0000 Message-ID: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> , <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> In-Reply-To: <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> Accept-Language: en-US Content-Language: en-US X-Hashtags: #Newsletters X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [107.77.206.112] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0277; 7:ADOmr27F0reXxipEbY8XPglopVM1MLT4k+zxp3d5uOcolbg7KHUci6pBuyisK17btkI5A2LzeUKmoPZjFelZpMX9x5B++XmSgXy86xHYg4p1dNCNEZhASamKGYhQkw5u1atPGlDkI6jgb0ibM7yNteBiOfsFCR6wLS+qsGiVU+tdK/R3X2jhoJqhklAXtcRxj86SRVLbBAYNvs1FWBzXCAjIiZmLWDiIiTQsVrJolhw0FDmtOTc84/fLRDgTfPqjroGK+j2rcrekw/FJSxpo5olFTxe920O7U991Elww44E8G5JJ/krYNPbQzfgQ4h4EX9HKZZkDqg1a5KWdKQWeY3/0qtsJsAa/ZUdJ9VOAM0oVdNOZJ5xFVVRVlHZoCFofl/gZjAXB9lQE/RQoyjIelFes7JAbQcyA9IerqEie9IVUiM5KkkgDP7sgNH03ojnTY9qlSGyHlhnfZ+6x2mKDsGVEkUjjGSwYqpaEq/OpnRh9aUcpra5o+QRVbUCzRJaOI/TRoYtopPx3g2h8E0NN7kvyqsOUdlmWzpZLlFsI2dFom5XiY/1PcE8Zo184hE5bndhKS1QhRBBl22PlJN7x+V7W717zCjmjaa7tHDWrkxP2Bxv5ASpt213KRkmJv0z38XYvcr5fqTF5JTNlUNpacPMknQpiCeG+DmG5Jj0YvXwucnI5/Aj0kJyEWY3PQqN2G6m2iMC1U+G74MIFK/sizjd9fjBzmT+w4o1Nr9Z1/SOlrAHf3z1nsKWlxjh6asEE5oy8aHFXZXS3wBsAqUgWpEhIDFWchdbjjPcPxihp6xsz4fprIcoA1JV9tFmvyPbH x-ms-office365-filtering-correlation-id: 3a22fccb-fcb7-4b7e-cb78-08d4b8ffaa57 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(48565401081)(300000503055)(300135400095)(201703131423075)(201703031133081)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:CY4PR21MB0277; x-ms-traffictypediagnostic: CY4PR21MB0277: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(131327999870524)(211936372134217)(21532816269658)(146099531331640)(47284530071512)(10436049006162)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0277; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0277; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(39400400002)(209900001)(51914003)(24454002)(377424004)(377454003)(81166006)(5005710100001)(53936002)(6306002)(6506006)(54896002)(236005)(9686003)(54906002)(99286003)(55016002)(561944003)(606005)(6436002)(16200700003)(53946003)(33656002)(38730400002)(53376002)(50986999)(76176999)(53386004)(54356999)(6246003)(39060400002)(8990500004)(102836003)(66066001)(189998001)(3846002)(6116002)(551544002)(10290500003)(2900100001)(7696004)(10090500001)(25786009)(53546010)(4326008)(77096006)(2906002)(3660700001)(3280700002)(8936002)(8676002)(14454004)(966005)(478600001)(72206003)(7736002)(2950100002)(229853002)(122556002)(93886004)(575784001)(86612001)(86362001)(74316002)(7906003)(5660300001)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0277; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504EB3DF824A845C282B4DDF5DA0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 23:45:57.9223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0277 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 23:46:08 -0000 --_000_CY4PR21MB0504EB3DF824A845C282B4DDF5DA0CY4PR21MB0504namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The proposal that I believe has the most support is keeping things as they = are, leaving it up to profiles and applications to define which claims they= use and how they use them. It would be fine for some profiles to use the language below. =96 Mike From: Phil Hunt Sent: Wednesday, June 21, 2017 6:39 PM To: Richard Backman, Annabelle Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Jus= tin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing Lis= t Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer So I understand what is being proposed is: If the event type uses =93sub=94 to identify its subject, and the issuer of= the subject is identical to the issuer for the event, then =93sub=94 may b= e used at the top level. Otherwise, the subject of an event (e.g. =93sub=94= ) and any other claims required to uniquely identify the subject MUST be co= ntained in the event payload. For example, an ip address of 1.2.3.4 might be represented in a =93ipaddres= s=94 claim defined in the event payload. =93ipaddress=94:=941.2.3.4" A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242= bd3859c82c4 might be identified in the event payload as: =93sub=94:"https:/= /scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=94 A Connect Logout event from an OP uses the top level sub claim and depends = on =93iss=94 being the same for the event issuer AND the subject. This mean= s that no party may issue logout events on behalf of the OP. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com phil.hunt@oracle.com On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle > wrote: Fair point. If we do not intend to support multiple profiles within a singl= e SET, then I=92m less concerned about leaving sub semantics up to the prof= iles. -- Annabelle Richard Backman Identity Services From: Marius Scurtescu = > Date: Wednesday, June 21, 2017 at 2:58 PM To: "Richard Backman, Annabelle" > Cc: "Phil Hunt (IDM)" >, = John Bradley >, Henk Birkholz <= henk.birkholz@sit.fraunhofer.de>, J= ustin Richer >, Yaron Sheffer >, Michael Jones >, ID Events Mailing L= ist > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer Example for multiple events within same profile: IdP account is disabled (b= ecause of hijacking), this can lead to two events: 1. "account-disabled" 2. "sessions-revoked" Marius On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle > wrote: The spec says that the events claim SHOULD NOT be used to express multiple = logical events. If it=92s also not used to express events from different pr= ofiles that correspond to the same logical event (e.g. an OIDC backchannel = logout event alongside a hypothetical RISC logout event), then I=92m not su= re what use case that leaves for multiple events in one SET. -- Annabelle Richard Backman Identity Services From: Id-event = > on behalf of "Phil Hunt (IDM)" > Date: Wednesday, June 21, 2017 at 2:12 PM To: John Bradley > Cc: "Richard Backman, Annabelle" >, Henk Birkholz >, Justin Richer >, Marius Scurtescu >= , Yaron Sheffer >, Mich= ael Jones >= , ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer Separate or combined may be evolving. Mike wants to keep the current backch= annel logout very narrowly scoped. He suggested risc define its own duplica= te definitions and meanings. That leads me to believe we will have multi-type events in practice. Session cancellation can occur for many reasons. One of the differentiators= we had tried to make was an assumption that user initiated events would be= part of connect. Risk would cover variations that drive off of risk calcul= ations like password reset. There are also signout events at rp's to let the OP know. These are not com= mands but notification that a resource session is cancelled. IOW single sig= n out not expected. Phil On Jun 21, 2017, at 1:58 PM, John Bradley > wrote: I thought we decided that we are only allowing set messages form the same f= amily that agree on top level claims. Otherwise there can be no top level claims and we are really defining a alt= ernative format to JWT in some ways. John B. On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle > wrote: I agree with John that the JWT type confusion problem and the SET sub probl= em can and should be discussed separately. The secevents WG is probably not= the right setting to discuss the former. My concern with the sub claim is that two profiles may dictate conflicting = semantics (e.g. Profile A says it=92s a phone number, Profile B says it=92s= an email address). If these profiles don=92t provide an alternate way to d= eclare subject of their events, then they cannot be present within the same= token. This incompatibility trap seems like something that could be easily= missed by groups profiling SET. -- Annabelle Richard Backman Identity Services From: John Bradley > Date: Wednesday, June 21, 2017 at 1:39 PM To: Yaron Sheffer > Cc: Justin Richer >, Marius Scurtes= cu >, Annabelle Richard= >, Phil Hunt >, Michael Jones >, ID Events Mailing List >, Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer In the envelope typ is a media/mime type. Registering application/idt+jwt = if we register jwt as a structured name sufix. Using the cty is also possible. I need to think about what is better but = we can agree on a convention. Not everything is going to be a set token like not every JWS is a JWT. If we are going to define processing rules to stop collisions and confusion= around JWT for different purposes, we should just start using the typ para= meter based on the existing spec. In general content sniffing if there is more than one option eventually get= s you into trouble. I am not convinced that forcing there to be no sub at the top level is a go= od idea. It is not the way we should differentiate between SET and id_tokens. If sub is not allowed at the top level people will do non SET JWT for thing= s where the subject is scoped to the iss of the token. I think defining sub to be part of the event for cases where the sub is sco= ped differently from the issuer of the token is fine, but should not be req= uired for all event types. I think we should solve the confusion issue separately from the sub issue. Sorry I am at CIS so trying to catch up on lists. John B. On Jun 17, 2017, at 3:45 PM, Yaron Sheffer > wrote: So to summarize what I'm seeing on this thread: Everybody agrees with Marius's short-term solution, specific rules for "sub= " and "iss" that can be defined in the SET spec. Almost everybody agrees on a long-term "usage" claim ("type" is taken) that= should be defined elsewhere, e.g. in the JWT BCP. Did I miss anything? By the way, if we do add a "usage" claim, we need to also use it in the SET= document before it is published. Thanks, Yaron On 15/06/17 22:08, Justin Richer wrote: +1 to this as well. =97 Justin On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: +1 to what Annabelle said. Also, Mike you are missing the other requirement, for RPs to send events to= an IdP. The iss+sub pair at the top level is broken in this case. Marius On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: +1 Phil On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle > wrote: Mike, Your explanation for why this is a non-problem is dependent upon side effec= ts of elements of OpenID Connect that were not designed to solve this issue= . As a result, I see several issues with it: 1. The caller of the Token Endpoint is the only party that can be cer= tain that a nonce-less ID Token is really an ID Token. Any party that the c= aller passes the ID Token off to has no way to verify its provenance. 2. Any future ID Token distribution method needs to solve this proble= m again. 3. No other profile of JWT can ever use the "nonce=94 claim. 4. This is only a solution for ID Tokens. Every other JWT profile that= cares about disambiguation has to invent its own solution to the problem. We know from experience that naming collisions and replay attacks are both = things that happen. What=92s being proposed is a simple, defensive measure = against these risks. You brought up JWT libraries: a general solution actua= lly makes it easier to use common libraries for JWT parsing. A =93usage-awa= re=94 JWT library could handle disambiguation for any JWT profile, whereas = with the status quo each profile would require unique logic. -- Annabelle Richard Backman Identity Services From: Id-event = > on behalf of Mike Jones > Date: Wednesday, June 14, 2017 at 1:16 PM To: Marius Scurtescu > Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer You=92ve heard of =93premature optimization=94. I=92d characterize the pro= posals in this thread as =93premature pessimation=94 =96 making things that= can and should be simple complex, without data showing there=92s any need = to do so. Mandatory solutions are being proposed in this thread to problems that ther= e=92s no evidence that we actually even have. It=92s already been establis= hed that it=92s impossible for a SET to be confused for an ID Token =96 see= https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html. If people have data showing that this is possib= le with specific kinds of Access Tokens or other real JWT deployments, plea= se provide specifics, so that we can use that data to inform appropriate en= gineering choices on our part. The proposed =93solutions=94, such as prohibiting the use of =93sub=94 in t= he normal way, or requiring a type claim, would make previously simple thin= gs unnecessarily complex. Yes, then the result is then different than a no= rmal JWT but a consequence of this is that custom parsing code would have t= o be used, rather than a standard JWT parser. The more unwieldy we make it= to use SETs, the more likely developers are to just create their own data = structures. Keeping it simple is the key to adoption. Standards are only = useful if they are actually used. -- Mike From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Back= man, Annabelle Sent: Tuesday, June 13, 2017 5:33 PM To: Marius Scurtescu >;= Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer Echoing Marius=92s question: can you explain what you mean by =93intend=94? To your first question, I think a better analogy would be the X.509 Key Usa= ge extension: a multi-valued property that declares the intended purpose of= the JWT, and that a recipient may refer to when determining whether to acc= ept a JWT being presented to it in some context. -- Annabelle Richard Backman Identity Services From: Id-event = > on behalf of Marius Scurtescu > Date: Tuesday, June 13, 2017 at 11:05 AM To: Henk Birkholz > Cc: ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz > wrote: And a 2nd question. What semantics would "usage" provide that that are not covered via "intend"= , "audience", and "scope"? "aud" (audience) specifies the target client, but not the intended usage (a= ccess token to authorize resource access or SET to communicate a security e= vent?) "scope" is not used by SET. I don't know what do you mean by "intend" (or intent)? Henk On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: Thanks for putting this together! I think the assumptions inherent in 3.9 are flawed: =B7We can=92t guarantee that every type of JWT will have a mutually exclusi= ve set of valid claims and/or header parameters, and enforcing this require= s a =93fail on an unrecognized claim=94 approach to ensure that JWTs from s= ome future spec can=92t be mistaken for JWTs from a current spec. =B7It is unrealistic to expect implementers to adhere to the =93different k= eys for different kinds of JWTs=94 rule. Whether mandated by the spec or no= t, implementers will ignore this because managing one key is easier than ma= naging N different keys. =B7Ditto for =93aud=94 and =93iss=94 claims. +1 for a =93type=94 or =93usage=94 claim/header parameter. -- Annabelle Richard Backman Identity Services *From: *Id-event > on behalf of Dick Hardt > *Date: *Monday, June 12, 2017 at 3:18 PM *To: *Marius Scurtescu = > *Cc: *Adam Dawes >, "matake, no= v" >, ID Events Mailing List >, "Phil Hunt (IDM)" > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer Agreed. Note that there is still lots of discussion on what should be in 3.= 9. On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu >> wrote: Thanks for the pointer Dick, very good timing :-) The issue is described by "2.7. Cross-JWT Confusion" and the mitigation is in "3.9. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs", specifically "Use different sets of required claims...", "Use different keys for different kinds of JWTs." and "Use different issuers for different kinds of JWTs.". I still think that a "type" claim would bring a lot of clarity and safety. Marius On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >> wrote: Yaron, Mike and I just published an BCP ID for JWT http://self-issued.info/?p=3D1690 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >> wrote: I was initially a fan of keeping SETS to be very similar to id tokens but I now think this is a better plan. On Thu, Jun 8, 2017 at 6:56 PM matake, nov >> wrote: +1 especially for "type" 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>: +1 Phil > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >> wrote: > > There were a couple of proposals on how to distinguish SETs from Id Tokens and Access Tokens in such a way that naive implementations will not confuse one for the other and open up security vulnerabilities. > > There is also another important requirement: the SET issuer in some cases must be different from the "sub" issuer. This is the case of an RP sending SETs to an IdP. > > With these requirements in mind I propose the following: > - both "sub" and "iss" to be defined at the event level > - "iss" at event level and at top SET level can be different > - "iss" and "sub" at event level can be different across events in the same SET > - "sub" should NOT be present at the top SET level (this solves the disambiguation), please note "should" and not "must" > > This solution also allows different profiles that define event types to define additional claims related to sub (like email or phone_number) and since all these claims will be at the event level there will be no collisions or ambiguity. > > Another proposal (which I supported) was to define a composite "aud" claim. This is not solving the requirement for a distinct SET issuer. Also, having the same claim name having different syntax in different token types could lead to confusion. > > And yet another proposal was to introduce a new claim for JWTs that defines a "type". This is not practical in the short term, and it also is not solving the distinct issuer requirement, but I think this is something the JWT group should seriously consider. > > Thoughts? > > Marius > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m= =3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn= 88YKOCd0mxPQFJLhxWI&e=3D _______________________________________________ Id-event mailing list Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event -- Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-21= 4-2410 > _______________________________________________ Id-event mailing list Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event -- Subscribe to the HARDTWARE > mail list to learn about projects I am working on! -- Subscribe to the HARDTWARE > mail list to learn about projects I am working= on! _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7= j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e= =3D _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_CY4PR21MB0504EB3DF824A845C282B4DDF5DA0CY4PR21MB0504namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The proposal that I believe has the most support is = keeping things as they are, leaving it up to profiles and applications to d= efine which claims they use and how they use them.

 

It would be fine for some profiles to use the langua= ge below.

 

=96 Mike

From: Phil Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabell= e
Cc: Marius Scurtescu; <= a href=3D"mailto:ve7jtb@ve7jtb.com"> John Bradley; Henk B= irkholz; Justin Richer; Yaron Sheffer; Mike Jone= s; ID Events Mailing List
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

 

So I understand what is being proposed is:

If the event type use= s =93sub=94 to identify its subject, and the issuer of the subject is ident= ical to the issuer for the event, then =93sub=94 may be used at the top lev= el. Otherwise, the subject of an event (e.g. =93sub=94) and any other claims required to uniquely identify the subject MUST be con= tained in the event payload.

For example, an ip address of 1.2.3.4 might be represented = in a =93ipaddress=94 claim defined in the event payload. =93ipaddress=94:= =941.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might b= e identified in the event payload as: =93sub=94:"https://s= cim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=94

A Connect Logout event from an OP uses the top level sub cl= aim and depends on =93iss=94 being the same for the event issuer AND the su= bject. This means that no party may issue logout events on behalf of the OP= .


Phil

Oracle Corporation, Identity Cloud Services Architect &= Standards
@independentid
www.ind= ependentid.com
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <= ;richanna@amazon.com&= gt; wrote:

Fair point. If we do not intend to support multiple profiles within a si= ngle SET, then I=92m less concerned about leaving sub semantics up to the p= rofiles.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
= From: Marius Scurtescu <<= a href=3D"mailto:mscurtescu@google.com" class=3D"">mscurtescu@google.com>
Date: W= ednesday, June 21, 2017 at 2:58 PM
To: &qu= ot;Richard Backman, Annabelle" <richanna@amazon.com>
Cc: &qu= ot;Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit= .fraunhofer.de>, Justin Richer <jricher@mi= t.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com&g= t;, ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET is= suer
 
Example for multiple events within same profile: IdP account is disabled (b= ecause of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the events claim SHOULD NOT be used to express multip= le logical events. If it=92s also not used to express events from different= profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypotheti= cal RISC logout event), then I=92m not sure what use case that leaves for m= ultiple events in one SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
= From: Id-event <id-event-bounces@ietf.org&= gt; on behalf of "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Date: W= ednesday, June 21, 2017 at 2:12 PM
To: Joh= n Bradley <ve7jtb@ve7jtb.co= m>
Cc: &qu= ot;Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.ed= u>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.i= etf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-= event@ietf.org>

Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET is= suer
 
Separate or combined may be evolving. Mike wants to keep the current backch= annel logout very narrowly scoped. He suggested risc define its own duplica= te definitions and meanings. 
 
That leads me to believe we will have multi-type events in practice.
 
Session cancellation can occur for many reasons. One of the differentiators= we had tried to make was an assumption that user initiated events would be= part of connect. Risk would cover variations that drive off of risk calcul= ations like password reset. 
 
There are also signout events at rp's to let the OP know. These are not com= mands but notification that a resource session is cancelled. IOW single sig= n out not expected. 

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing set messages form the same f= amily that agree on top level claims.
 
Otherwise there can be no top level claims and we are really defining a alt= ernative format to JWT in some ways.
 
John B.
 
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
 
I agree with John that the JWT type confusion problem and the SET sub pr= oblem can and should be discussed separately. The secevents WG is probably = not the right setting to discuss the former.
 
My concern with the sub claim is that two profiles may dictate conflicti= ng semantics (e.g. Profile A says it=92s a phone number, Profile B says it= =92s an email address). If these profiles don=92t provide an alternate way to declare subject of their events, then = they cannot be present within the same token. This incompatibility trap see= ms like something that could be easily missed by groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
= From: J= ohn Bradley <ve7jtb@ve7jtb.c= om>
Date: Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richan= na@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Mi= chael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusio= n and distinct SET issuer
 
In the envelope typ is a media/mime type.  Registering application/idt= +jwt if we register jwt as a structured name sufix.  
 
Using the cty is also possible.   I need to think about what is better= but we can agree on a convention.
 
Not everything is going to be a set token like not every JWS is a JWT.
 
If we are going to define processing rules to stop collisions and confusion= around JWT for different purposes, we should just start using the typ para= meter based on the existing spec.
 
In general content sniffing if there is more than one option eventually get= s you into trouble.
 
I am not convinced that forcing there to be no sub at the top level is a go= od idea.  
 
It is not the way we should differentiate between SET and id_tokens.
 
If sub is not allowed at the top level people will do non SET JWT for thing= s where the subject is scoped to the iss of the token.
 
I think defining sub to be part of the event for cases where the sub is sco= ped differently from the issuer of the token is fine, but should not be req= uired for all event types.
 
I think we should solve the confusion issue separately from the sub issue.<= o:p class=3D"">
 
Sorry I am at CIS so trying to catch up on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@g= mail.com> wrote:
 
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specific rules for &quo= t;sub" and "iss" that can be defined in the SET spec.
Almost everybody agrees on a long-term "usage" claim ("type&= quot; is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it = in the SET document before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well. 
 
 =97 Justin
 
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu= @google.com> wrote:
 
+1 to what Annabelle said. 
 
Also, Mike you are missing the other requirement, for RPs to send events to= an IdP. The iss+sub pair at the top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hun= t@oracle.com> wrote:
+1
 
Phil

 

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
 
Your explanation for why this is a non-problem is dependent upon side ef= fects of elements of OpenID Connect that were not designed to solve this is= sue. As a result, I see several issues with it:

1.   &n= bsp;  =  The caller of the Token Endpoint is the only party that can be certain that a = nonce-less ID Token is really an ID Token. Any party that the caller passes= the ID Token off to has no way to verify its provenance.

2.   &n= bsp;  =  Any future ID Token distribution method needs to solve this problem again.

3.      = No other profile of JWT can ever use the "nonce=94 claim.

4.      = This is only a solution for ID Tokens. Every other JWT profile that cares about= disambiguation has to invent its own solution to the problem.

 
We know from experience that naming collisions and replay attacks are bo= th things that happen. What=92s being proposed is a simple, defensive measu= re against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common l= ibraries for JWT parsing. A =93usage-aware=94 JWT library could handle disa= mbiguation for any JWT profile, whereas with the status quo each profile wo= uld require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
= From: I= d-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.c= om>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com= >
Cc: "Richard Backman, Annabelle" <r= ichanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, He= nk Birkholz <henk.birkholz@sit.fraunhofer.de<= /span>>
Subject: Re: [Id-event] solution for Id/Access Token confusio= n and distinct SET issuer
 
You=92ve heard of =93premature optimization=94.  I=92d charac= terize the proposals in this thread as =93premature pessimation=94 =96 maki= ng things that can and should be simple complex, without data showing there=92s any need to do so.
 
Mandatory solutions are being proposed in this thread to problems = that there=92s no evidence that we actually even have.  It=92s already= been established that it=92s impossible for a SET to be confused for an ID Token =96 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of A= ccess Tokens or other real JWT deployments, please provide specifics, so th= at we can use that data to inform appropriate engineering choices on our pa= rt.
 
The proposed =93solutions=94, such as prohibiting the use of =93su= b=94 in the normal way, or requiring a type claim, would make previously si= mple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this i= s that custom parsing code would have to be used, rather than a standard JW= T parser.  The more unwieldy we make it to use SETs, the more likely d= evelopers are to just create their own data structures.  Keeping it simple is the key to adoption.  Sta= ndards are only useful if they are actually used.
 
           =             &nb= sp;            =             -- Mike<= /span>
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of = Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com= >; Henk Birkholz <henk.birkholz@sit.fraunhofer.de= >
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusio= n and distinct SET issuer
 
Echoing Marius=92s question: can you explain what you mean by =93intend= =94?
 
To your first question, I think a better analogy would be the X.509 Key = Usage extension: a multi-valued property that declares the intended purpose= of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in= some context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
= From: I= d-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@= sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusio= n and distinct SET issuer
 
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?
 
"aud" (audience) specifies the target client, but not the intende= d usage (access token to authorize resource access or SET to communicate a = security event?)
 
"scope" is not used by SET.
 
I don't know what do you mean by "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=B7We can=92t guarantee that every type of JWT will have a mutually exclusi= ve set of valid claims and/or header parameters, and enforcing this require= s a =93fail on an unrecognized claim=94 approach to ensure that JWTs from s= ome future spec can=92t be mistaken for JWTs from a current spec.

=B7It is unrealistic to expect implementers to adhere to the =93different k= eys for different kinds of JWTs=94 rule. Whether mandated by the spec or no= t, implementers will ignore this because managing one key is easier than ma= naging N different keys.

=B7Ditto for =93aud=94 and =93iss=94 claims.

+1 for a =93type=94 or =93usage=94 claim/header parameter.

-- <= br class=3D"">
Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com= >
*Cc: *Adam Dawes <adawes@google.com>, "mat= ake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, &q= uot;Phil Hunt (IDM)" <phil.hunt@oracle.com= >
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurt= escu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion"= ; and the
    mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
    Different Kinds of JWTs", specifically "Use differe= nt sets of
    required claims...", "Use different keys for differ= ent kinds of
    JWTs." and "Use different issuers for different kin= ds of JWTs.".

    I still think that a "type" claim would bring a lot= of clarity and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <= dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>&= gt; wrote:

        Yaron, Mike and I just published an BCP ID for = JWT
        http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" style=3D"color: purpl= e; text-decoration: underline;" class=3D"">adawes@google.com
        <mailto:adawes@google.com<= /a>>> wrote:

            I was initially a fan of keeping = SETS to be very similar to
            id tokens but I now think this is= a better plan.

            On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
            <mailto:nov@matake.jp>> wrote:

                +1 especially f= or "type"

                2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
                <p= hil.hunt@oracle.com<mailto:phil.hunt@oracle.com= >>:

                    += 1

                    Phil<= br class=3D"">

                     = ;> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" style=3D"color: p= urple; text-decoration: underline;" class=3D"">mscurtescu@google.com
                    <m= ailto:mscurtescu@google.com>> wrote:
                     = ;>
                     = ;> There were a couple of proposals on how to
                    disti= nguish SETs from Id Tokens and Access Tokens in
                    such = a way that naive implementations will not
                    confu= se one for the other and open up security
                    vulne= rabilities.
                     = ;>
                     = ;> There is also another important requirement: the
                    SET i= ssuer in some cases must be different from the
                    "= ;sub" issuer. This is the case of an RP sending SETs
                    to an= IdP.
                     = ;>
                     = ;> With these requirements in mind I propose the
                    follo= wing:
                     = ;> - both "sub" and "iss" to be defined at the event=
                    level=
                     = ;> - "iss" at event level and at top SET level can
                    be di= fferent
                     = ;> - "iss" and "sub" at event level can be different=
                    acros= s events in the same SET
                     = ;> - "sub" should NOT be present at the top SET
                    level= (this solves the disambiguation), please note
                    "= ;should" and not "must"
                     = ;>
                     = ;> This solution also allows different profiles that
                    defin= e event types to define additional claims
                    relat= ed to sub (like email or phone_number) and
                    since= all these claims will be at the event level
                    there= will be no collisions or ambiguity.
                     = ;>
                     = ;> Another proposal (which I supported) was to
                    defin= e a composite "aud" claim. This is not solving
                    the r= equirement for a distinct  SET issuer. Also,
                    havin= g the same claim name having different syntax
                    in di= fferent token types could lead to confusion.
                     = ;>
                     = ;> And yet another proposal was to introduce a new
                    claim= for JWTs that defines a "type". This is not
                    pract= ical in the short term, and it also is not
                    solvi= ng the distinct issuer requirement, but I think
                    this = is something the JWT group should seriously
                    consi= der.
                     = ;>
                     = ;> Thoughts?
                     = ;>
                     = ;> Marius

                     = ;> _______________________________________________
                     = ;> Id-event mailing list

                     = ;> Id-event@ietf.org <mailto:Id-event@ietf.o= rg>
                     = ;>
                    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQc= xBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am= p;m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDw= VqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                    _____= __________________________________________
                    Id-ev= ent mailing list
                    Id-event@ietf.org <mailto:Id-event@ietf.org>
                    https://www.ietf.org/mailman/listinfo/id-event

                ___________________= ____________________________
                Id-event mailing li= st
                Id-event@iet= f.org=  <mailto:Id-event@ietf.org>
                https://w= ww.ietf.org/mailman/listinfo/id-event

            -- 
            Adam Dawes | Sr. Product Manager = |adawes@google.com
            <mailto:adawes@goog= le.com> |+1 650-214-2410
            <tel:(650)%20214-24= 10>

            _________________________________= ______________
            Id-event mailing list
            Id-event@ietf.org &= lt;mailto:Id-event@ietf.org>
            https://www.ietf.org/= mailman/listinfo/id-event

        -- 
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



-- <= br class=3D"">
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ie= tf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZ= YR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKF= ZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D<= /div>
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 




______________________=
_________________________
Id-event mailing list<=
o:p class=3D"">
Id-event@ie=
tf.org
https://=
www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman= /listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman= /listinfo/id-event
 

--_000_CY4PR21MB0504EB3DF824A845C282B4DDF5DA0CY4PR21MB0504namp_-- From nobody Wed Jun 21 17:16:50 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30734126DD9 for ; Wed, 21 Jun 2017 17:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw7sCQA-ilae for ; Wed, 21 Jun 2017 17:16:43 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48B7126D74 for ; Wed, 21 Jun 2017 17:16:43 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id m62so41832537itc.0 for ; Wed, 21 Jun 2017 17:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zyf0Q5p0rm3RVcGG6++pkTnzf7wDVmwUbQGPlqjMUAU=; b=fWshX9Zwk0lSi2lCEk4ADvVSpOXOtvgEyqyqLWxwnmAqM9RW8JNQoZI5h7xT8l9kyu PasyS7k5Y4dsOqnCFVBB0Qq6+/KZNXeLnBuLmNxQtOT6AuD0TkVbyTNc92mCGpWMxzKI 8b+qDzdSk5qaF1aHGqAsBIVrZ01mghxg6sYD/deIRbcPqaxJZglKtiwdZIc7NJd+3yhm oIco7w5xKt2645N9f0101xzMKLDR4RAqqBN2tpeceCCXUb04a4rLFp6Q/4Qunh6yqy9N 7SLoFx+FOlEGMuDoGKv8FST0+WXn0d71d0bXGSu5aY43xgY6mGKG5/jn/ivaMQ6ic3Ni Q/GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zyf0Q5p0rm3RVcGG6++pkTnzf7wDVmwUbQGPlqjMUAU=; b=A6kVq81wiMrDsSHjJ+e+yTlIENQy/Lrs9RKPJBxsgDdHp8oejyD/DB1a0oiTKGyMfB PhDMKcqoum4L+Vw1Ll77l7RwuxuuZkUCObbBDp5KRyy9gNusAbGoM1BnCJc5RSkrUt17 By+6kJhVaM0l4Ku4SB/IHbDXtw8QG3pRXV9ce+I8ZaXjJMrZI9NRr7PCA54q47MSyjYe xeU4eDO32JfmKaBglPhKGS+U5wAwtDFQuBKSBiDqe60DNgQrkqHOi9D4ex96yE77pmZC MlnOa29LWJ5MCyzQMRkNqytzyEMQAitj8Bk5F5uumsHcuWWBWAWYWxIFsvpFbuJTlW+p 2IVA== X-Gm-Message-State: AKS2vOyNl2ImD92KPv2Kh5kaRR6k2GqDWmXc1yG4TvKJ4BHrw2W0rYcB vF9YmLWxEkJkYobwXnjsql93R/seNpLk X-Received: by 10.36.135.204 with SMTP id f195mr6324980ite.91.1498090602518; Wed, 21 Jun 2017 17:16:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Wed, 21 Jun 2017 17:16:21 -0700 (PDT) In-Reply-To: References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> From: Marius Scurtescu Date: Wed, 21 Jun 2017 17:16:21 -0700 Message-ID: To: Mike Jones Cc: Phil Hunt , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c11bde234f01d05528166ee" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 00:16:49 -0000 --94eb2c11bde234f01d05528166ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones wrote: > The proposal that I believe has the most support is keeping things as the= y > are, leaving it up to profiles and applications to define which claims th= ey > use and how they use them. > > > > It would be fine for some profiles to use the language below. > I don't think this is acceptable Mike. I'll summarize again. We have two open problem to solve: 1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in particular). 2. In some cases there is an "iss" conflict at the top level, the "sub" related "iss" is different from the SET "iss". This is not specific to any particular profile. Further, problem 1 needs a short term solution and a long term solution. The important solution for secevent is the short term one. Out of the above only the long term solution for problem 1 has some promising resolution (using typ or cty). So, keeping things as they are nothing relevant to secevent is solved basically. Again, if your main concern is compatibility for the logout spec (which is understandable) then let's talk about that and see if we can find a solution for the two problems above with that constraint. Unfortunately I cannot see such a solution. > > > =E2=80=93 Mike > > *From: *Phil Hunt > *Sent: *Wednesday, June 21, 2017 6:39 PM > *To: *Richard Backman, Annabelle > *Cc: *Marius Scurtescu ; John Bradley > ; Henk Birkholz ; Jus= tin > Richer ; Yaron Sheffer ; Mike > Jones ; ID Events Mailing List > > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > So I understand what is being proposed is: > > If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, and= the issuer of > the subject is identical to the issuer for the event, then =E2=80=9Csub= =E2=80=9D may be > used at the top level. Otherwise, the subject of an event (e.g. =E2=80=9C= sub=E2=80=9D) and > any other claims required to uniquely identify the subject MUST be > contained in the event payload. > > For example, an ip address of 1.2.3.4 might be represented in a > =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. =E2=80=9C= ipaddress=E2=80=9D:=E2=80=9D1.2.3.4" > A SCIM resource URI of https://scim.example.com/users/ > ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload > as: =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45c= e9a242bd3859c82c4 > =E2=80=9D > > A Connect Logout event from an OP uses the top level sub claim and depend= s > on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the subj= ect. This means > that no party may issue logout events on behalf of the OP. > > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Fair point. If we do not intend to support multiple profiles within a > single SET, then I=E2=80=99m less concerned about leaving sub semantics u= p to the > profiles. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Marius Scurtescu > *Date: *Wednesday, June 21, 2017 at 2:58 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"Phil Hunt (IDM)" , John Bradley < > ve7jtb@ve7jtb.com>, Henk Birkholz , > Justin Richer , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Example for multiple events within same profile: IdP account is disabled > (because of hijacking), this can lead to two events: > 1. "account-disabled" > 2. "sessions-revoked" > > Marius > > On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The spec says that the events claim SHOULD NOT be used to express multipl= e > logical events. If it=E2=80=99s also not used to express events from diff= erent > profiles that correspond to the same logical event (e.g. an OIDC > backchannel logout event alongside a hypothetical RISC logout event), the= n > I=E2=80=99m not sure what use case that leaves for multiple events in one= SET. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Id-event on behalf of "Phil Hunt > (IDM)" > *Date: *Wednesday, June 21, 2017 at 2:12 PM > *To: *John Bradley > *Cc: *"Richard Backman, Annabelle" , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>, Justin Richer , Marius > Scurtescu , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Separate or combined may be evolving. Mike wants to keep the current > backchannel logout very narrowly scoped. He suggested risc define its own > duplicate definitions and meanings. > > That leads me to believe we will have multi-type events in practice. > > Session cancellation can occur for many reasons. One of the > differentiators we had tried to make was an assumption that user initiate= d > events would be part of connect. Risk would cover variations that drive o= ff > of risk calculations like password reset. > > There are also signout events at rp's to let the OP know. These are not > commands but notification that a resource session is cancelled. IOW singl= e > sign out not expected. > > Phil > > > On Jun 21, 2017, at 1:58 PM, John Bradley wrote: > > I thought we decided that we are only allowing set messages form the same > family that agree on top level claims. > > Otherwise there can be no top level claims and we are really defining a > alternative format to JWT in some ways. > > John B. > > > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > I agree with John that the JWT type confusion problem and the SET sub > problem can and should be discussed separately. The secevents WG is > probably not the right setting to discuss the former. > > My concern with the sub claim is that two profiles may dictate conflictin= g > semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B say= s it=E2=80=99s an > email address). If these profiles don=E2=80=99t provide an alternate way = to declare > subject of their events, then they cannot be present within the same toke= n. > This incompatibility trap seems like something that could be easily misse= d > by groups profiling SET. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *John Bradley > *Date: *Wednesday, June 21, 2017 at 1:39 PM > *To: *Yaron Sheffer > *Cc: *Justin Richer , Marius Scurtescu < > mscurtescu@google.com>, Annabelle Richard , Phil > Hunt , Michael Jones , > ID Events Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > In the envelope typ is a media/mime type. Registering application/idt+jw= t > if we register jwt as a structured name sufix. > > Using the cty is also possible. I need to think about what is better bu= t > we can agree on a convention. > > Not everything is going to be a set token like not every JWS is a JWT. > > If we are going to define processing rules to stop collisions and > confusion around JWT for different purposes, we should just start using t= he > typ parameter based on the existing spec. > > In general content sniffing if there is more than one option eventually > gets you into trouble. > > I am not convinced that forcing there to be no sub at the top level is a > good idea. > > It is not the way we should differentiate between SET and id_tokens. > > If sub is not allowed at the top level people will do non SET JWT for > things where the subject is scoped to the iss of the token. > > I think defining sub to be part of the event for cases where the sub is > scoped differently from the issuer of the token is fine, but should not b= e > required for all event types. > > I think we should solve the confusion issue separately from the sub issue= . > > Sorry I am at CIS so trying to catch up on lists. > > John B. > > > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote: > > So to summarize what I'm seeing on this thread: > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > Did I miss anything? > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > Thanks, > Yaron > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > =E2=80=94 Justin > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > +1 to what Annabelle said. > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > Marius > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > "scope" is not used by SET. > > I don't know what do you mean by "intend" (or intent)? > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > <%2B1%20650-214-2410> > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > --94eb2c11bde234f01d05528166ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 21, 2017 at 4:45 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

The proposal that I believe has the most support is = keeping things as they are, leaving it up to profiles and applications to d= efine which claims they use and how they use them.

=C2=A0

It would be fine for some profiles to use the langua= ge below.


I don't think= this is acceptable Mike.

I'll summarize again= .

We have two open problem to solve:
1. = SETs could be confused for other JWTs (Id Tokens and Access Tokens in parti= cular).
2. In some cases there is an "iss" conflict at = the top level, the "sub" related "iss" is different fro= m the SET "iss". This is not specific to any particular profile.<= /div>

Further, problem 1 needs a short term solution and= a long term solution. The important solution for secevent is the short ter= m one.

Out of the above only the long term solutio= n for problem 1 has some promising resolution (using typ or cty).

So, keeping things as they are nothing relevant to secevent= is solved basically.

Again, if your main concern = is compatibility for the logout spec (which is understandable) then let'= ;s talk about that and see if we can find a solution for the two problems a= bove with that constraint. Unfortunately I cannot see such a solution.



=C2=A0

=C2=A0

=E2=80=93 Mike

From: Phil = Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justi= n Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So I understand what is being proposed is:

If the event type uses =E2=80=9Csub=E2=80= =9D to identify its subject, and the issuer of the subject is identical to = the issuer for the event, then =E2=80=9Csub=E2=80=9D may be used at the top= level. Otherwise, the subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims required to uniquely identify the subject MUST be con= tained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a =E2=80= =9Cipaddress=E2=80=9D claim defined in the event payload. =E2=80=9Cipaddres= s=E2=80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload as: =E2=80=9Csub=E2=80=9D:= "https://scim.example.com/use= rs/ac1faebbfd3c45ce9a242bd3859c82c4=E2=80=9D

A Connect Logout event from an OP uses the top level sub claim and dep= ends on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the s= ubject. This means that no party may issue logout events on behalf of the O= P.


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards<= /div>
@independentid
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@am= azon.com> wrote:

Fair point. I= f we do not intend to support multiple profiles within a single SET, then I= =E2=80=99m less concerned about leaving sub semantics up to the profiles.
=C2=A0=
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0=
=C2=A0=
From:=C2=A0Marius Scurtescu <mscurtescu@google= .com>
Date:=C2=A0Wednesday, June 21, 2017 at 2:58 PM
To:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>=
Cc:=C2=A0"Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Br= adley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkhol= z@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail= .com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>
Subject:=C2=A0= Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer
=C2=A0
Example for multiple events within same profile: IdP account is disabled (b= ecause of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
=C2=A0
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= /u>
The spec says= that the events claim SHOULD NOT be used to express multiple logical event= s. If it=E2=80=99s also not used to express events from different profiles = that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypotheti= cal RISC logout event), then I=E2=80=99m not sure what use case that leaves= for multiple events in one SET.
=C2=A0=
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0=
=C2=A0=
From:=C2=A0Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Date:=C2=A0Wednesday, June 21, 2017 at 2:12 PM
To:=C2=A0John Bradley <ve7jtb= @ve7jtb.com>
Cc:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fra= unhofer.de>, Justin Richer <jricher@mit.= edu>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf= .ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <i= d-event@ietf.org>

Subject:=C2=A0= Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer
=C2=A0
Separate or combined may be evolving. Mike wants to keep the current backch= annel logout very narrowly scoped. He suggested risc define its own duplica= te definitions and meanings.=C2=A0
=C2=A0
That leads me to believe we will have multi-type events in practice.=
=C2=A0
Session cancellation can occur for many reasons. One of the differentiators= we had tried to make was an assumption that user initiated events would be= part of connect. Risk would cover variations that drive off of risk calcul= ations like password reset.=C2=A0
=C2=A0
There are also signout events at rp's to let the OP know. These are not= commands but notification that a resource session is cancelled. IOW single= sign out not expected.=C2=A0

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing set messages form the same f= amily that agree on top level claims.
=C2=A0
Otherwise there can be no top level claims and we are really defining a alt= ernative format to JWT in some ways.
=C2=A0
John B.
=C2=A0
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= u>
=C2=A0
I agree with = John that the JWT type confusion problem and the SET sub problem can and sh= ould be discussed separately. The secevents WG is probably not the right se= tting to discuss the former.
=C2=A0=
My concern wi= th the sub claim is that two profiles may dictate conflicting semantics (e.= g. Profile A says it=E2=80=99s a phone number, Profile B says it=E2=80=99s = an email address). If these profiles don=E2=80=99t provide an alternate way to declare subject of their events,= then they cannot be present within the same token. This incompatibility tr= ap seems like something that could be easily missed by groups profiling SET= .
=C2=A0=
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0=
=C2=A0=
From:=C2=A0John Bradley <ve7jtb@ve7jtb.com>
Date:=C2=A0Wednesday, June 21, 2017 at 1:39 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <rich= anna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <= Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=C2=A0Re: [Id-event] solution for Id/Access Token= confusion and distinct SET issuer
=C2=A0
In the envelope typ is a media/mime type.=C2=A0 Registering application/idt= +jwt if we register jwt as a structured name sufix. =C2=A0
=C2=A0
Using the cty is also possible. =C2=A0 I need to think about what is better= but we can agree on a convention.
=C2=A0
Not everything is going to be a set token like not every JWS is a JWT.
=C2=A0
If we are going to define processing rules to stop collisions and confusion= around JWT for different purposes, we should just start using the typ para= meter based on the existing spec.
=C2=A0
In general content sniffing if there is more than one option eventually get= s you into trouble.
=C2=A0
I am not convinced that forcing there to be no sub at the top level is a go= od idea. =C2=A0
=C2=A0
It is not the way we should differentiate between SET and id_tokens.=
=C2=A0
If sub is not allowed at the top level people will do non SET JWT for thing= s where the subject is scoped to the iss of the token.
=C2=A0
I think defining sub to be part of the event for cases where the sub is sco= ped differently from the issuer of the token is fine, but should not be req= uired for all event types.
=C2=A0
I think we should solve the confusion issue separately from the sub issue.<= u>
=C2=A0
Sorry I am at CIS so trying to catch up on lists.
=C2=A0
John B.
=C2=A0
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=C2=A0
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specific rules for = "sub" and "iss" that can be defined in the SET spec.=
Almost everybody agrees on a long-term "usage" claim ("type&= quot; is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it = in the SET document before it is published.
Thanks,
=C2=A0=C2=A0=C2=A0 Yaron
=C2=A0
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well.=C2=A0
=C2=A0
=C2=A0=E2=80=94 Justin
=C2=A0
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com= > wrote:
=C2=A0
+1 to what Annabelle said.=C2=A0
=C2=A0
Also, Mike you are missing the other requirement, for RPs to send events to= an IdP. The iss+sub pair at the top level is broken in this case.

Marius
=C2=A0
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.= com> wrote:
+1
=C2=A0
Phil

=C2=A0

On Jun 14, 2= 017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,<= u>
=C2=A0=
Your explanat= ion for why this is a non-problem is dependent upon side effects of element= s of OpenID Connect that were not designed to solve this issue. As a result= , I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>= The caller of the Token Endpoint is the only party that can be certain that a = nonce-less ID Token is really an ID Token. Any party that the caller passes= the ID Token off to has no way to verify its provenance.<= /u>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>= Any future ID Token distribution method needs to solve this problem again.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0No other profile of JWT can ever use the "nonce=E2=80=9D claim.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This is only a solution for ID Tokens. Every other JWT profile that cares about= disambiguation has to invent its own solution to the problem.

=C2=A0=
We know from = experience that naming collisions and replay attacks are both things that h= appen. What=E2=80=99s being proposed is a simple, defensive measure against= these risks. You brought up JWT libraries: a general solution actually makes it easier to use common l= ibraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could= handle disambiguation for any JWT profile, whereas with the status quo eac= h profile would require unique logic.
=C2=A0=
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0=
=C2=A0=
From:=C2=A0Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com= >
Date:=C2=A0Wednesday, June 14, 2017 at 1:16 PM
To:=C2=A0Marius Scurtescu <mscurtescu@google.com>
Cc:=C2=A0"Richard Backman, Annabelle" <ric= hanna@amazon.com>, ID Events Mailing List <<= span style=3D"color:purple">id-event@ietf.org>, Henk Birkholz= <henk.birkholz@sit.fraunhofer.de>
Subject:=C2=A0Re: [Id-event] solution for Id/Access Token= confusion and distinct SET issuer
=C2=A0
You=E2=80= =99ve heard of =E2=80=9Cpremature optimization=E2=80=9D.=C2=A0 I=E2=80=99d = characterize the proposals in this thread as =E2=80=9Cpremature pessimation= =E2=80=9D =E2=80=93 making things that can and should be simple complex, wi= thout data showing there=E2=80=99s any need to do so.
=C2=A0
Mandatory= solutions are being proposed in this thread to problems that there=E2=80= =99s no evidence that we actually even have.=C2=A0 It=E2=80=99s already bee= n established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93 see=C2=A0https://www.ietf.org/mail-archive/web/id-event/cur= rent/msg00428.html.=C2=A0 If people have data showing that this is possible with specific kinds of A= ccess Tokens or other real JWT deployments, please provide specifics, so th= at we can use that data to inform appropriate engineering choices on our pa= rt.
=C2=A0
The propo= sed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csu= b=E2=80=9D in the normal way, or requiring a type claim, would make previou= sly simple things unnecessarily complex.=C2=A0 Yes, then the result is then different than a normal JWT but a consequence of this i= s that custom parsing code would have to be used, rather than a standard JW= T parser.=C2=A0 The more unwieldy we make it to use SETs, the more likely d= evelopers are to just create their own data structures.=C2=A0 Keeping it simple is the key to adoption.=C2=A0 Sta= ndards are only useful if they are actually used.
=C2=A0
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
From:=C2= =A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Richard Backman, Annabelle
Sent:=C2=A0Tuesday, June 13, 2017 5:33 PM
To:=C2=A0Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:=C2=A0ID Events Mailing List <id-event@ietf.org>
Subject:=C2=A0Re: [Id-event] solution for Id/Access Token= confusion and distinct SET issuer
=C2=A0
Echoing Mariu= s=E2=80=99s question: can you explain what you mean by =E2=80=9Cintend=E2= =80=9D?
=C2=A0=
To your first= question, I think a better analogy would be the X.509 Key Usage extension:= a multi-valued property that declares the intended purpose of the JWT, and= that a recipient may refer to when determining whether to accept a JWT being presented to it in= some context.
=C2=A0=
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0=
=C2=A0=
From:=C2=A0Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com&g= t;
Date:=C2=A0Tuesday, June 13, 2017 at 11:05 AM
To:=C2=A0Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Cc:=C2=A0ID Events Mailing List <id-event@ietf.org>
Subject:=C2=A0Re: [Id-event] solution for Id/Access Token= confusion and distinct SET issuer
=C2=A0
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkh= olz@sit.fraunhofer.de> wrote:
And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?
=C2=A0
"aud" (audience) specifies the target client, but not the intende= d usage (access token to authorize resource access or SET to communicate a = security event?)
=C2=A0
"scope" is not used by SET.
=C2=A0
I don't know what do you mean by "intend" (or intent)?=
=C2=A0
=C2=A0


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

--=C2=A0

Annabelle Richard Backman

Identity Services

*From: *Id-event <= id-event-bounces@ietf.org> on be= half of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov&qu= ot; <nov@matake.jp>, ID Events Mailing List <<= span style=3D"color:purple">id-event@ietf.org>, "Phil Hu= nt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google= .com<mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@= gmail.com
=C2=A0 =C2=A0 <mailto:<= span style=3D"color:purple">dick.hardt@gmail.com>> wrote:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0http://self-issued.info/?p=3D1690<= /span>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" style=3D"color:purple;text-decoration:u= nderline" target=3D"_blank" class=3D"cremed">a= dawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com>&g= t; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp&g= t;> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@or= acle.com<mailto:phil.hunt@oracle.com>&g= t;:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" style=3D"color:purple;text-decorati= on:underline" target=3D"_blank" class=3D"cremed">mscurtescu@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= ailto:mscurtescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>=C2=A0Id-event@ietf.org=C2=A0<ma= ilto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-<= wbr>3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJ= Bm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74= AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88Y= KOCd0mxPQFJLhxWI&e=3D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-= event@ietf.org=C2=A0<mailto:Id-event@ietf.org= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.org= =C2=A0<mailto:Id-event@ietf.org&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ie= tf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--=C2=A0

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
= Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=


_______________________________________________
Id-event mailing list
= Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=
=C2=A0
=C2=A0
_______________________________________________
Id-event mailing list
= Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=
=C2=A0




_________________________________=
______________
Id-event mailing list

Id-event@ietf.org=



https://www.ietf.org/mailman/listinfo/id-event
=C2=A0
_______________________________________________
Id-event mailing list
= Id-event@ietf.org
https://www.ietf.org/mailm= an/listinfo/id-event
=C2=A0
=C2=A0
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailm= an/listinfo/id-event
=C2=A0


--94eb2c11bde234f01d05528166ee-- From nobody Wed Jun 21 17:25:57 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077EC126DD9 for ; Wed, 21 Jun 2017 17:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fez-3T8e4GrI for ; Wed, 21 Jun 2017 17:25:50 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF15120721 for ; Wed, 21 Jun 2017 17:25:49 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5M0PgSl027454 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 00:25:43 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5M0Pffj019087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 00:25:41 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5M0PcdK015020; Thu, 22 Jun 2017 00:25:38 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Jun 2017 17:25:37 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-263BAA30-2D41-4109-82CF-75E969800083 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 21 Jun 2017 17:25:34 -0700 Cc: Mike Jones , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Justin Richer , Yaron Sheffer , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <618AD3DC-778F-4C8F-B60A-92F5BDCB14F2@oracle.com> References: <4BD645F0-F594-48C2-8601-4721B2289436@oracle.com> <1EE56A12-E2A2-400D-A561-8C6818C8BAA9@amazon.com> <45396fbc-63b4-fce3-15be-a3280572dbb4@sit.fraunhofer.de> <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3! @gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> To: Marius Scurtescu X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 00:25:55 -0000 --Apple-Mail-263BAA30-2D41-4109-82CF-75E969800083 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Phil > On Jun 21, 2017, at 5:16 PM, Marius Scurtescu wrot= e: >=20 >> On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones = wrote: >> The proposal that I believe has the most support is keeping things as the= y are, leaving it up to profiles and applications to define which claims the= y use and how they use them. >>=20 >> =20 >>=20 >> It would be fine for some profiles to use the language below. >>=20 >=20 > I don't think this is acceptable Mike. >=20 > I'll summarize again. >=20 > We have two open problem to solve: > 1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in p= articular). > 2. In some cases there is an "iss" conflict at the top level, the "sub" re= lated "iss" is different from the SET "iss". This is not specific to any par= ticular profile. >=20 > Further, problem 1 needs a short term solution and a long term solution. T= he important solution for secevent is the short term one. >=20 > Out of the above only the long term solution for problem 1 has some promis= ing resolution (using typ or cty). >=20 > So, keeping things as they are nothing relevant to secevent is solved basi= cally. >=20 > Again, if your main concern is compatibility for the logout spec (which is= understandable) then let's talk about that and see if we can find a solutio= n for the two problems above with that constraint. Unfortunately I cannot se= e such a solution. >=20 >=20 >=20 > =20 >> =20 >>=20 >> =E2=80=93 Mike >>=20 >> From: Phil Hunt >> Sent: Wednesday, June 21, 2017 6:39 PM >> To: Richard Backman, Annabelle >> Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin Richer; Yaron S= heffer; Mike Jones; ID Events Mailing List >>=20 >>=20 >> Subject: Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer >> =20 >>=20 >> So I understand what is being proposed is: >>=20 >> If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, and= the issuer of the subject is identical to the issuer for the event, then =E2= =80=9Csub=E2=80=9D may be used at the top level. Otherwise, the subject of a= n event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims required to unique= ly identify the subject MUST be contained in the event payload. >>=20 >> For example, an ip address of 1.2.3.4 might be represented in a =E2=80=9C= ipaddress=E2=80=9D claim defined in the event payload. =E2=80=9Cipaddress=E2= =80=9D:=E2=80=9D1.2.3.4" >> A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a2= 42bd3859c82c4 might be identified in the event payload as: =E2=80=9Csub=E2=80= =9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=E2=80=9D= >>=20 >> A Connect Logout event from an OP uses the top level sub claim and depend= s on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the subje= ct. This means that no party may issue logout events on behalf of the OP. >>=20 >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle wrote: >>>=20 >>> Fair point. If we do not intend to support multiple profiles within a si= ngle SET, then I=E2=80=99m less concerned about leaving sub semantics up to t= he profiles. >>> =20 >>> --=20 >>> Annabelle Richard Backman >>> Identity Services >>> =20 >>> =20 >>> From: Marius Scurtescu >>> Date: Wednesday, June 21, 2017 at 2:58 PM >>> To: "Richard Backman, Annabelle" >>> Cc: "Phil Hunt (IDM)" , John Bradley , Henk Birkholz , Justin Richer , Yaron Sheffer , Michael Jones , ID Events Mailing List >>> Subject: Re: [Id-event] solution for Id/Access Token confusion and disti= nct SET issuer >>> =20 >>> Example for multiple events within same profile: IdP account is disabled= (because of hijacking), this can lead to two events: >>> 1. "account-disabled" >>> 2. "sessions-revoked" >>>=20 >>> Marius >>> =20 >>>> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle wrote: >>>> The spec says that the events claim SHOULD NOT be used to express multi= ple logical events. If it=E2=80=99s also not used to express events from dif= ferent profiles that correspond to the same logical event (e.g. an OIDC back= channel logout event alongside a hypothetical RISC logout event), then I=E2=80= =99m not sure what use case that leaves for multiple events in one SET. >>>> =20 >>>> --=20 >>>> Annabelle Richard Backman >>>> Identity Services >>>> =20 >>>> =20 >>>> From: Id-event on behalf of "Phil Hunt (IDM= )" >>>> Date: Wednesday, June 21, 2017 at 2:12 PM >>>> To: John Bradley >>>> Cc: "Richard Backman, Annabelle" , Henk Birkholz <= henk.birkholz@sit.fraunhofer.de>, Justin Richer , Marius Sc= urtescu , Yaron Sheffer , Mich= ael Jones , ID Events Mailing List >>>>=20 >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and dist= inct SET issuer >>>> =20 >>>> Separate or combined may be evolving. Mike wants to keep the current ba= ckchannel logout very narrowly scoped. He suggested risc define its own dupl= icate definitions and meanings.=20 >>>> =20 >>>> That leads me to believe we will have multi-type events in practice. >>>> =20 >>>> Session cancellation can occur for many reasons. One of the differentia= tors we had tried to make was an assumption that user initiated events would= be part of connect. Risk would cover variations that drive off of risk calc= ulations like password reset.=20 >>>> =20 >>>> There are also signout events at rp's to let the OP know. These are not= commands but notification that a resource session is cancelled. IOW single s= ign out not expected.=20 >>>>=20 >>>> Phil >>>>=20 >>>>=20 >>>>> On Jun 21, 2017, at 1:58 PM, John Bradley wrote: >>>>> I thought we decided that we are only allowing set messages form the s= ame family that agree on top level claims. >>>>> =20 >>>>> Otherwise there can be no top level claims and we are really defining a= alternative format to JWT in some ways. >>>>> =20 >>>>> John B. >>>>> =20 >>>>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle wrote: >>>>>> =20 >>>>>> I agree with John that the JWT type confusion problem and the SET sub= problem can and should be discussed separately. The secevents WG is probabl= y not the right setting to discuss the former. >>>>>> =20 >>>>>> My concern with the sub claim is that two profiles may dictate confli= cting semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B s= ays it=E2=80=99s an email address). If these profiles don=E2=80=99t provide a= n alternate way to declare subject of their events, then they cannot be pres= ent within the same token. This incompatibility trap seems like something th= at could be easily missed by groups profiling SET. >>>>>> =20 >>>>>> --=20 >>>>>> Annabelle Richard Backman >>>>>> Identity Services >>>>>> =20 >>>>>> =20 >>>>>> From: John Bradley >>>>>> Date: Wednesday, June 21, 2017 at 1:39 PM >>>>>> To: Yaron Sheffer >>>>>> Cc: Justin Richer , Marius Scurtescu , Annabelle Richard , Phil Hunt , Michael Jones , ID Events Mailing List= , Henk Birkholz >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer >>>>>> =20 >>>>>> In the envelope typ is a media/mime type. Registering application/id= t+jwt if we register jwt as a structured name sufix. =20 >>>>>> =20 >>>>>> Using the cty is also possible. I need to think about what is bette= r but we can agree on a convention. >>>>>> =20 >>>>>> Not everything is going to be a set token like not every JWS is a JWT= . >>>>>> =20 >>>>>> If we are going to define processing rules to stop collisions and con= fusion around JWT for different purposes, we should just start using the typ= parameter based on the existing spec. >>>>>> =20 >>>>>> In general content sniffing if there is more than one option eventual= ly gets you into trouble. >>>>>> =20 >>>>>> I am not convinced that forcing there to be no sub at the top level i= s a good idea. =20 >>>>>> =20 >>>>>> It is not the way we should differentiate between SET and id_tokens. >>>>>> =20 >>>>>> If sub is not allowed at the top level people will do non SET JWT for= things where the subject is scoped to the iss of the token. >>>>>> =20 >>>>>> I think defining sub to be part of the event for cases where the sub i= s scoped differently from the issuer of the token is fine, but should not be= required for all event types. >>>>>> =20 >>>>>> I think we should solve the confusion issue separately from the sub i= ssue. >>>>>> =20 >>>>>> Sorry I am at CIS so trying to catch up on lists. >>>>>> =20 >>>>>> John B. >>>>>> =20 >>>>>>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer w= rote: >>>>>>> =20 >>>>>>> So to summarize what I'm seeing on this thread: >>>>>>> Everybody agrees with Marius's short-term solution, specific rules f= or "sub" and "iss" that can be defined in the SET spec. >>>>>>> Almost everybody agrees on a long-term "usage" claim ("type" is take= n) that should be defined elsewhere, e.g. in the JWT BCP. >>>>>>> Did I miss anything? >>>>>>> By the way, if we do add a "usage" claim, we need to also use it in t= he SET document before it is published. >>>>>>> Thanks, >>>>>>> Yaron >>>>>>> =20 >>>>>>>> On 15/06/17 22:08, Justin Richer wrote: >>>>>>>> +1 to this as well.=20 >>>>>>>> =20 >>>>>>>> =E2=80=94 Justin >>>>>>>> =20 >>>>>>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu wrote: >>>>>>>>> =20 >>>>>>>>> +1 to what Annabelle said.=20 >>>>>>>>> =20 >>>>>>>>> Also, Mike you are missing the other requirement, for RPs to send e= vents to an IdP. The iss+sub pair at the top level is broken in this case. >>>>>>>>>=20 >>>>>>>>> Marius >>>>>>>>> =20 >>>>>>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wrote: >>>>>>>>>> +1 >>>>>>>>>> =20 >>>>>>>>>> Phil >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >>>>>>>>>>> Mike, >>>>>>>>>>> =20 >>>>>>>>>>> Your explanation for why this is a non-problem is dependent upon= side effects of elements of OpenID Connect that were not designed to solve t= his issue. As a result, I see several issues with it: >>>>>>>>>>> 1. The caller of the Token Endpoint is the only party that= can be certain that a nonce-less ID Token is really an ID Token. Any party t= hat the caller passes the ID Token off to has no way to verify its provenanc= e. >>>>>>>>>>>=20 >>>>>>>>>>> 2. Any future ID Token distribution method needs to solve t= his problem again. >>>>>>>>>>>=20 >>>>>>>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D= claim. >>>>>>>>>>>=20 >>>>>>>>>>> 4. This is only a solution for ID Tokens. Every other JWT p= rofile that cares about disambiguation has to invent its own solution to the= problem. >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> We know from experience that naming collisions and replay attack= s are both things that happen. What=E2=80=99s being proposed is a simple, de= fensive measure against these risks. You brought up JWT libraries: a general= solution actually makes it easier to use common libraries for JWT parsing. A= =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for a= ny JWT profile, whereas with the status quo each profile would require uniqu= e logic. >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> From: Id-event on behalf of Mike Jon= es >>>>>>>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>>>>>>> To: Marius Scurtescu >>>>>>>>>>> Cc: "Richard Backman, Annabelle" , ID Event= s Mailing List , Henk Birkholz >>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion a= nd distinct SET issuer >>>>>>>>>>> =20 >>>>>>>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D= . I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematu= re pessimation=E2=80=9D =E2=80=93 making things that can and should be simpl= e complex, without data showing there=E2=80=99s any need to do so. >>>>>>>>>>> =20 >>>>>>>>>>> Mandatory solutions are being proposed in this thread to problem= s that there=E2=80=99s no evidence that we actually even have. It=E2=80=99s= already been established that it=E2=80=99s impossible for a SET to be confu= sed for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-e= vent/current/msg00428.html. If people have data showing that this is possib= le with specific kinds of Access Tokens or other real JWT deployments, pleas= e provide specifics, so that we can use that data to inform appropriate engi= neering choices on our part. >>>>>>>>>>> =20 >>>>>>>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting th= e use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim,= would make previously simple things unnecessarily complex. Yes, then the r= esult is then different than a normal JWT but a consequence of this is that c= ustom parsing code would have to be used, rather than a standard JWT parser.= The more unwieldy we make it to use SETs, the more likely developers are t= o just create their own data structures. Keeping it simple is the key to ad= option. Standards are only useful if they are actually used. >>>>>>>>>>> =20 >>>>>>>>>>> -- Mike >>>>>>>>>>> =20 >>>>>>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of R= ichard Backman, Annabelle >>>>>>>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>>>>>>> To: Marius Scurtescu ; Henk Birkholz >>>>>>>>>>> Cc: ID Events Mailing List >>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion a= nd distinct SET issuer >>>>>>>>>>> =20 >>>>>>>>>>> Echoing Marius=E2=80=99s question: can you explain what you mean= by =E2=80=9Cintend=E2=80=9D? >>>>>>>>>>> =20 >>>>>>>>>>> To your first question, I think a better analogy would be the X.= 509 Key Usage extension: a multi-valued property that declares the intended p= urpose of the JWT, and that a recipient may refer to when determining whethe= r to accept a JWT being presented to it in some context. >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> From: Id-event on behalf of Marius S= curtescu >>>>>>>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>>>>>>> To: Henk Birkholz >>>>>>>>>>> Cc: ID Events Mailing List >>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion a= nd distinct SET issuer >>>>>>>>>>> =20 >>>>>>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: >>>>>>>>>>>> And a 2nd question. >>>>>>>>>>>>=20 >>>>>>>>>>>> What semantics would "usage" provide that that are not covered v= ia "intend", "audience", and "scope"? >>>>>>>>>>> =20 >>>>>>>>>>> "aud" (audience) specifies the target client, but not the intend= ed usage (access token to authorize resource access or SET to communicate a s= ecurity event?) >>>>>>>>>>> =20 >>>>>>>>>>> "scope" is not used by SET. >>>>>>>>>>> =20 >>>>>>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Henk >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will h= ave a mutually exclusive set of valid claims and/or header parameters, and e= nforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D app= roach to ensure that JWTs from some future spec can=E2=80=99t be mistaken fo= r JWTs from a current spec. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =C2=B7It is unrealistic to expect implementers to adhere to th= e =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. Whether= mandated by the spec or not, implementers will ignore this because managing= one key is easier than managing N different keys. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D= claims. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D cla= im/header parameter. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Identity Services >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *From: *Id-event on behalf of Dick= Hardt >>>>>>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>>>>>> *To: *Marius Scurtescu >>>>>>>>>>>>> *Cc: *Adam Dawes , "matake, nov" , ID Events Mailing List , "Phil Hunt (IDM)" >>>>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token confusi= on and distinct SET issuer >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Agreed. Note that there is still lots of discussion on what sh= ould be in 3.9. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" and t= he >>>>>>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive Validation R= ules for >>>>>>>>>>>>> Different Kinds of JWTs", specifically "Use different sets= of >>>>>>>>>>>>> required claims...", "Use different keys for different kin= ds of >>>>>>>>>>>>> JWTs." and "Use different issuers for different kinds of J= WTs.". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I still think that a "type" claim would bring a lot of cla= rity and >>>>>>>>>>>>> safety. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Marius >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>>>>>> http://self-issued.info/?p=3D1690 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I was initially a fan of keeping SETS to be very s= imilar to >>>>>>>>>>>>> id tokens but I now think this is a better plan. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 especially for "type" >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>>>>>> >: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius Scur= tescu >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > There were a couple of proposals on how= to >>>>>>>>>>>>> distinguish SETs from Id Tokens and Access= Tokens in >>>>>>>>>>>>> such a way that naive implementations will= not >>>>>>>>>>>>> confuse one for the other and open up secu= rity >>>>>>>>>>>>> vulnerabilities. >>>>>>>>>>>>> > >>>>>>>>>>>>> > There is also another important require= ment: the >>>>>>>>>>>>> SET issuer in some cases must be different= from the >>>>>>>>>>>>> "sub" issuer. This is the case of an RP se= nding SETs >>>>>>>>>>>>> to an IdP. >>>>>>>>>>>>> > >>>>>>>>>>>>> > With these requirements in mind I propo= se the >>>>>>>>>>>>> following: >>>>>>>>>>>>> > - both "sub" and "iss" to be defined at= the event >>>>>>>>>>>>> level >>>>>>>>>>>>> > - "iss" at event level and at top SET l= evel can >>>>>>>>>>>>> be different >>>>>>>>>>>>> > - "iss" and "sub" at event level can be= different >>>>>>>>>>>>> across events in the same SET >>>>>>>>>>>>> > - "sub" should NOT be present at the to= p SET >>>>>>>>>>>>> level (this solves the disambiguation), pl= ease note >>>>>>>>>>>>> "should" and not "must" >>>>>>>>>>>>> > >>>>>>>>>>>>> > This solution also allows different pro= files that >>>>>>>>>>>>> define event types to define additional cl= aims >>>>>>>>>>>>> related to sub (like email or phone_number= ) and >>>>>>>>>>>>> since all these claims will be at the even= t level >>>>>>>>>>>>> there will be no collisions or ambiguity. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Another proposal (which I supported) wa= s to >>>>>>>>>>>>> define a composite "aud" claim. This is no= t solving >>>>>>>>>>>>> the requirement for a distinct SET issuer= . Also, >>>>>>>>>>>>> having the same claim name having differen= t syntax >>>>>>>>>>>>> in different token types could lead to con= fusion. >>>>>>>>>>>>> > >>>>>>>>>>>>> > And yet another proposal was to introdu= ce a new >>>>>>>>>>>>> claim for JWTs that defines a "type". This= is not >>>>>>>>>>>>> practical in the short term, and it also i= s not >>>>>>>>>>>>> solving the distinct issuer requirement, b= ut I think >>>>>>>>>>>>> this is something the JWT group should ser= iously >>>>>>>>>>>>> consider. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thoughts? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Marius >>>>>>>>>>>>>=20 >>>>>>>>>>>>> > _______________________________________= ________ >>>>>>>>>>>>> > Id-event mailing list >>>>>>>>>>>>> > Id-event@ietf.org >>>>>>>>>>>>> > >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1Yum= CXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe= 4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NG= DwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D >>>>>>>>>>>>>=20 >>>>>>>>>>>>> __________________________________________= _____ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-e= vent >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ______________________________________________= _ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event= >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Adam Dawes | Sr. Product Manager |adawes@google.co= m >>>>>>>>>>>>> |+1 650-214-2410 >>>>>>>>>>>>> >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Subscribe to the HARDTWARE mai= l list to >>>>>>>>>>>>> learn about projects I am working on! >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Subscribe to the HARDTWARE mail list t= o learn about projects I am working on! >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5= YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7J= PKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7Tm= GMSWWs&e=3D >>>>>>>>>=20 >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>> =20 >>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>=20 >>> =20 >>=20 >=20 --Apple-Mail-263BAA30-2D41-4109-82CF-75E969800083 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Phil

On Jun 21= , 2017, at 5:16 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The proposal that I believe has the most support is k= eeping things as they are, leaving it up to profiles and applications to def= ine which claims they use and how they use them.

 

It would be fine for some profiles to use the languag= e below.


I don't think this i= s acceptable Mike.

I'll summarize again.
=
We have two open problem to solve:
1. SETs could be= confused for other JWTs (Id Tokens and Access Tokens in particular).
<= div>2. In some cases there is an "iss" conflict at the top level, the "sub" r= elated "iss" is different from the SET "iss". This is not specific to any pa= rticular profile.

Further, problem 1 needs a short t= erm solution and a long term solution. The important solution for secevent i= s the short term one.

Out of the above only the lon= g term solution for problem 1 has some promising resolution (using typ or ct= y).

So, keeping things as they are nothing relevant= to secevent is solved basically.

Again, if your ma= in concern is compatibility for the logout spec (which is understandable) th= en let's talk about that and see if we can find a solution for the two probl= ems above with that constraint. Unfortunately I cannot see such a solution.<= /div>



 

 

=E2=80=93 Mike

From: Phil Hu= nt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin= Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List


Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer

 

So I understand what is being proposed is:

If the event type uses =E2=80=9Csub=E2=80=9D= to identify its subject, and the issuer of the subject is identical to the i= ssuer for the event, then =E2=80=9Csub=E2=80=9D may be used at the top level= . Otherwise, the subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims required to uniquely identify the subject MUST be cont= ained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a =E2=80=9C= ipaddress=E2=80=9D claim defined in the event payload. =E2=80=9Cipaddress=E2= =80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82= c4 might be identified in the event payload as: =E2=80=9Csub=E2=80=9D:"<= a href=3D"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4" t= arget=3D"_blank" class=3D"cremed">https://scim.example.com/users/a= c1faebbfd3c45ce9a242bd3859c82c4=E2=80=9D

A Connect Logout event from an OP uses the top level sub claim and depe= nds on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the sub= ject. This means that no party may issue logout events on behalf of the OP.<= /div>


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@amaz= on.com> wrote:

Fair point. If= we do not intend to support multiple profiles within a single SET, then I=E2= =80=99m less concerned about leaving sub semantics up to the profiles.
 <= u>
-- 
Annabelle Richard Backman
Identity Services
 <= u>
 <= u>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Wednesday, June 21, 2017 at 2:58 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@v= e7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.= de>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.co= m>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>
Subject: <= /span>Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer
 
Example for multiple events within same profile: IdP account is disabled (be= cause of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= u>
The spec says t= hat the events claim SHOULD NOT be used to express multiple logical events. I= f it=E2=80=99s also not used to express events from different profiles that c= orrespond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetic= al RISC logout event), then I=E2=80=99m not sure what use case that leaves f= or multiple events in one SET.
 <= u>
-- 
Annabelle Richard Backman
Identity Services
 <= u>
 <= u>
From: Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Date: Wednesday, June 21, 2017 at 2:12 PM
To: John Bradley <ve7jtb@ve= 7jtb.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<= /a>>, Justin Richer <jricher@mit.ed= u>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.i= etf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-= event@ietf.org>

Subject: <= /span>Re: [Id-event] solution for Id/Access Token confusion and distinct= SET issuer
 
Separate or combined may be evolving. Mike wants to keep the current backcha= nnel logout very narrowly scoped. He suggested risc define its own duplicate= definitions and meanings. 
 
That leads me to believe we will have multi-type events in practice.<= u>
 
Session cancellation can occur for many reasons. One of the differentiators w= e had tried to make was an assumption that user initiated events would be pa= rt of connect. Risk would cover variations that drive off of risk calculatio= ns like password reset. 
 
There are also signout events at rp's to let the OP know. These are not comm= ands but notification that a resource session is cancelled. IOW single sign o= ut not expected. 

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing set messages form the same fa= mily that agree on top level claims.
 
Otherwise there can be no top level claims and we are really defining a alte= rnative format to JWT in some ways.
 
John B.
 
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:<= /u>
 
I agree with J= ohn that the JWT type confusion problem and the SET sub problem can and shou= ld be discussed separately. The secevents WG is probably not the right setti= ng to discuss the former.
 <= u>
My concern wit= h the sub claim is that two profiles may dictate conflicting semantics (e.g.= Profile A says it=E2=80=99s a phone number, Profile B says it=E2=80=99s an e= mail address). If these profiles don=E2=80=99t provide an alternate way to declare subject of their events, t= hen they cannot be present within the same token. This incompatibility trap s= eems like something that could be easily missed by groups profiling SET.
 <= u>
-- 
Annabelle Richard Backman
Identity Services
 <= u>
 <= u>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richan= na@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Mi= chael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <= henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token c= onfusion and distinct SET issuer
 
In the envelope typ is a media/mime type.  Registering application/idt+= jwt if we register jwt as a structured name sufix.  
 
Using the cty is also possible.   I need to think about what is better b= ut we can agree on a convention.
 
Not everything is going to be a set token like not every JWS is a JWT.
 
If we are going to define processing rules to stop collisions and confusion a= round JWT for different purposes, we should just start using the typ paramet= er based on the existing spec.
 
In general content sniffing if there is more than one option eventually gets= you into trouble.
 
I am not convinced that forcing there to be no sub at the top level is a goo= d idea.  
 
It is not the way we should differentiate between SET and id_tokens.<= u>
 
If sub is not allowed at the top level people will do non SET JWT for things= where the subject is scoped to the iss of the token.
 
I think defining sub to be part of the event for cases where the sub is scop= ed differently from the issuer of the token is fine, but should not be requi= red for all event types.
 
I think we should solve the confusion issue separately from the sub issue.
 
Sorry I am at CIS so trying to catch up on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specific rules for "sub"= and "iss" that can be defined in the SET spec.
Almost everybody agrees on a long-term "usage" claim ("type" is taken) that s= hould be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it in the SET d= ocument before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well. 
 
 =E2=80=94 Justin
 
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what Annabelle said. 
 
Also, Mike you are missing the other requirement, for RPs to send events to a= n IdP. The iss+sub pair at the top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
 
Phil

 

On Jun 14, 20= 17, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
 <= u>
Your explanati= on for why this is a non-problem is dependent upon side effects of elements o= f OpenID Connect that were not designed to solve this issue. As a result, I s= ee several issues with it:

1.       The caller of the Token Endpoint is the only party that can be certain that a n= once-less ID Token is really an ID Token. Any party that the caller passes t= he ID Token off to has no way to verify its provenance.=

2.       Any future ID Token distribution method needs to solve this problem again.

3.      No other profile of JWT can ever use the "nonce=E2=80=9D claim.<= u>

4.      This is only a solution for ID Tokens. Every other JWT profile that cares about d= isambiguation has to invent its own solution to the problem.

 <= u>
We know from e= xperience that naming collisions and replay attacks are both things that hap= pen. What=E2=80=99s being proposed is a simple, defensive measure against th= ese risks. You brought up JWT libraries: a general solution actually makes it easier to use common li= braries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could h= andle disambiguation for any JWT profile, whereas with the status quo each p= rofile would require unique logic.
 <= u>
-- 
Annabelle Richard Backman
Identity Services
 <= u>
 <= u>
From: Id-event <id-e= vent-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com&g= t;
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.c= om>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz &l= t;henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token c= onfusion and distinct SET issuer
 
You=E2=80=99= ve heard of =E2=80=9Cpremature optimization=E2=80=9D.  I=E2=80=99d char= acterize the proposals in this thread as =E2=80=9Cpremature pessimation=E2=80= =9D =E2=80=93 making things that can and should be simple complex, without data showing there=E2=80=99s any need to do so.
 
Mandatory s= olutions are being proposed in this thread to problems that there=E2=80=99s n= o evidence that we actually even have.  It=E2=80=99s already been estab= lished that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/m= sg00428.html.  If people have data showing that this is possible with specific kinds of Ac= cess Tokens or other real JWT deployments, please provide specifics, so that= we can use that data to inform appropriate engineering choices on our part.=
 
The propos= ed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2= =80=9D in the normal way, or requiring a type claim, would make previously s= imple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this is= that custom parsing code would have to be used, rather than a standard JWT p= arser.  The more unwieldy we make it to use SETs, the more likely devel= opers are to just create their own data structures.  Keeping it simple is the key to adoption.  Stan= dards are only useful if they are actually used.
 
 &nbs= p;            &n= bsp;            =             = ;         -- Mike
 
From: = = Id-event [mailto:id-event-bounces@ietf.org] = On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <= henk.birkholz@sit.fraunhofer.de= >
Cc: ID Events Mailing List <id-event@ietf.org<= /a>>
Subject: Re: [Id-event] solution for Id/Access Token c= onfusion and distinct SET issuer
 
Echoing Marius= =E2=80=99s question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D= ?
 <= u>
To your first q= uestion, I think a better analogy would be the X.509 Key Usage extension: a m= ulti-valued property that declares the intended purpose of the JWT, and that= a recipient may refer to when determining whether to accept a JWT being presented to it in s= ome context.
 <= u>
-- 
Annabelle Richard Backman
Identity Services
 <= u>
 <= u>
 
And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend",= "audience", and "scope"?
 
"aud" (audience) specifies the target client, but not the intended usage (ac= cess token to authorize resource access or SET to communicate a security eve= nt?)
 
"scope" is not used by SET.
 
I don't know what do you mean by "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutually= exclusive set of valid claims and/or header parameters, and enforcing this r= equires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure= that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdif= ferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by t= he spec or not, implementers will ignore this because managing one key is ea= sier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header para= meter.

-- 

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behal= f of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <= mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.= jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)= " <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinc= t SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9= .

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com= <mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the     mitigation is in "3.9. Use Mutually Exclusive Validation Rules= for
    Different Kinds of JWTs", specifically "Use different sets of<= br>     required claims...", "Use different keys for different kinds o= f
    JWTs." and "Use different issuers for different kinds of JWTs.= ".

    I still think that a "type" claim would bring a lot of clarity= and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gma= il.com
    <mailto:dick.hardt@gmail.com>> wrote:
=
        Yaron, Mike and I just published an BCP ID for J= WT
        = http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adaw= es@google.com
        <mailto:adawes@google.com>> wro= te:

            I was initially a fan of keeping S= ETS to be very similar to
            id tokens but I now think this is a= better plan.

            On Thu, Jun 8, 2017 at 6:56 PM mat= ake, nov <nov@matake.jp
            <mailto:nov@matake.jp>&= gt; wrote:

                +1 especially for "t= ype"

                2017-06-09 10:32 GMT= +09:00 Phil Hunt (IDM)
                <phil.hunt@oracl= e.com<mailto:<= span style=3D"color:purple">phil.hunt@oracle.com>>:
                    +1
=
                    Phil

                     = > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <= mscurtescu@google.com
                    <ma= ilto:mscurtescu@google.com>> wrote:
                     = >
                     = > There were a couple of proposals on how to
                    distin= guish SETs from Id Tokens and Access Tokens in
                    such a= way that naive implementations will not
                    confus= e one for the other and open up security
                    vulner= abilities.
                     = >
                     = > There is also another important requirement: the
                    SET is= suer in some cases must be different from the
                    "sub" i= ssuer. This is the case of an RP sending SETs
                    to an I= dP.
                     = >
                     = > With these requirements in mind I propose the
                    follow= ing:
                     = > - both "sub" and "iss" to be defined at the event
                    level<= br>                      = > - "iss" at event level and at top SET level can
                    be dif= ferent
                     = > - "iss" and "sub" at event level can be different
                    across= events in the same SET
                     = > - "sub" should NOT be present at the top SET
                    level (= this solves the disambiguation), please note
                    "shoul= d" and not "must"
                     = >
                     = > This solution also allows different profiles that
                    define= event types to define additional claims
                    relate= d to sub (like email or phone_number) and
                    since a= ll these claims will be at the event level
                    there w= ill be no collisions or ambiguity.
                     = >
                     = > Another proposal (which I supported) was to
                    define= a composite "aud" claim. This is not solving
                    the re= quirement for a distinct  SET issuer. Also,
                    having= the same claim name having different syntax
                    in dif= ferent token types could lead to confusion.
                     = >
                     = > And yet another proposal was to introduce a new
                    claim f= or JWTs that defines a "type". This is not
                    practi= cal in the short term, and it also is not
                    solvin= g the distinct issuer requirement, but I think
                    this i= s something the JWT group should seriously
                    consid= er.
                     = >
                     = > Thoughts?
                     = >
                     = > Marius

                     = > _______________________________________________
                     = > Id-event mailing list

                     = > Id-event@ietf.org <mailto:I= d-event@ietf.org>
                     = >
                   &nbs= p;https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.i= etf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRo= P1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0Fk= ITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvg= Xzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJL= hxWI&e=3D

                    ______= _________________________________________
                    Id-eve= nt mailing list
                   &nbs= p;Id-event@ietf.org <mailto:Id-event@ie= tf.org>
                   &nbs= p;https://www.ietf.org/mailman/listinfo/id-event

                ____________________= ___________________________
                Id-event mailing lis= t
                Id-even= t@ietf.org <mailto:Id-event@ietf.org>
                https://w= ww.ietf.org/mailman/listinfo/id-event

            -- 
            Adam Dawes | Sr. Product Manager |= ad= awes@google.com
            <mailto:adawes@google.com<= /a>> |+1 650-214-2410
            <tel:(650)%20214-2410&= gt;

            _______________________________________________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/<= wbr>mailman/listinfo/id-event

        -- 
        Subscribe to the HARDTWARE <= http://hardtware.com/> mail list to
        learn about projects I am working on!



-- 

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id= -event@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id= -event@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id= -event@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/id-event
 




____________________________________________=
___
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<=
/span>
 
_______________________________________________
Id-event mailing list
Id= -event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 


= --Apple-Mail-263BAA30-2D41-4109-82CF-75E969800083-- From nobody Thu Jun 22 10:05:07 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3C3129AFF for ; Thu, 22 Jun 2017 10:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI60tzbyqigb for ; Thu, 22 Jun 2017 10:05:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334CE127B52 for ; Thu, 22 Jun 2017 10:05:03 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5MH52Yc014693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 Jun 2017 17:05:02 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5MH51G4005327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 Jun 2017 17:05:02 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5MH51DD001520 for ; Thu, 22 Jun 2017 17:05:01 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jun 2017 10:05:01 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_0F6D31CD-EB6B-4EC5-BEC4-80B2D4CE6FE4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> Date: Thu, 22 Jun 2017 10:05:00 -0700 To: ID Events Mailing List X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:05:05 -0000 --Apple-Mail=_0F6D31CD-EB6B-4EC5-BEC4-80B2D4CE6FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99ve had a long standing thread on how to handle use of = =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET. I=E2=80=99d = like to give some examples that we can compare. Please add your comments. It would be good to reach some conclusion in = the next few days if we are going to change the draft for Prague. Thanks! Three current draft examples: 1. A SCIM Event looks like: > {=20 > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://security.example.com", =20 > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], =20 > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > "events": { > "urn:ietf:params:scim:event:passwordReset": { } > } > } 2. An OP issued Backchannel Logout (single-sign-out) looks like: > { > "iss": "https://server.example.com", > "sub": "248289761001", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02", > "events": { > "http://schemas.openid.net/event/backchannel-logout": {} > } > } 3. An RP issued Application Logout Looks like (different issuer): > { > "iss": "https://rp.example.com", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "events": { > "http://schemas.openid.net/event/risc-logout": { > "sub": "248289761001", > "iss": "https://server.example.com=E2=80=9D, > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > } > } > } I believe the concerns here are: Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent = and moves around. =20 SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its = own attribute in the payload (introducing more variability). As long as = =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can = redefine sub for their own purposes. Is this good or bad? Those writing parsers have to be concerned that when they are parsing a = SET they need to know the role of the server OR they have to fully parse = the entire object to determine if they are looking at structure 2 or 3. = IOW a lot of implementations have to always check for an embedded = =E2=80=9Ciss=E2=80=9D to be sure they have the correct subject. A concern about the trade-offs if multiple event types are expressed, = should they share a common top-level attribute. How does this improve or = complicate multi-type events? In the draft, note that Figure 1 shows an = event with a localized extension that adds value without impacting = inter-op. =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the = top-level. We=E2=80=99ve been discussing that additional attributes = should be in the payload. Item 3 shows sid in the payload. Which is = correct? =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D A. We could say that all SETs must embed sub and iss (if they use iss = for identifying subjects) in the payload. See example 3 above. This = would exclude options 1 and 2 and at least make it consistent that = subject information is always in the payload. =20 B. A new top-level attribute could be defined which is a JSON object. = Inside the JSON object, profiling specs can define how their subjects = are addressed. Let=E2=80=99s call it target. A new common SET format = might look something like: {=20 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "iat": 1458496025, "iss": "https://security.example.com", =20 "aud": [ "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" ], =20 "target":{ "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", "iss": "https://scim.example.com" }, "events": { "urn:ietf:params:scim:event:passwordReset": { } } } Here is an example modified logout=20 { "iss": "https://server.example.com", "aud": "s6BhdRkqt3", "iat": 1471566154, "jti": "bWJq=E2=80=9D, =E2=80=9Ctarget=E2=80=9D:{ "sub": "248289761001", "sid": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D } "events": { "http://schemas.openid.net/event/backchannel-logout": {} } } The above formats address the following: * Consistent structures * Flexibility for profiles to target differently but using a common = attribute * Multiple event types share a common target and must be compatible (not = sure if this is a plus or minus) * No conflict around SET issuer vs subject issuer * SET is substantially different such that existing access token and ID = token code will reject consistently (because sub is missing) * target could also have an attribute that indicates the target = =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, IPaddress, and = so on. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_0F6D31CD-EB6B-4EC5-BEC4-80B2D4CE6FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99ve had a long standing thread on how to handle use = of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET.  I=E2=80=99= d like to give some examples that we can compare.

Please add your comments. It would be = good to reach some conclusion in the next few days if we are going to = change the draft for Prague.

Thanks!
Three current draft = examples:

1. A = SCIM Event looks like:
{ 
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "aud": [
  =   "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /div>
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",<= /div>
  "events": {
    = "urn:ietf:params:scim:event:passwordReset": { }
  }
}

2. An OP issued = Backchannel Logout (single-sign-out) looks like:
  =  {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
      }
   }

3. An RP issued = Application Logout Looks like (different issuer):
{
   = "iss": "https://rp.example.com",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "jti": "bWJq",
   "events": {
       "sub": = "248289761001",
   =     "iss": "https://server.example.com=E2=80=9D,
  =      "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"
   =   }
   }
}

I believe the concerns here = are:

  • Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2= =80=9D is inconsistent and moves around.  
  • SCIM = could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its own = attribute in the payload (introducing more variability).  As long = as =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can = redefine sub for their own purposes.  Is this good or bad?
  • Those writing parsers have to be concerned that when they are = parsing a SET they need to know the role of the server OR they have to = fully parse the entire object to determine if they are looking at = structure 2 or 3.  IOW a lot of implementations have to always = check for an embedded =E2=80=9Ciss=E2=80=9D to be sure they have the = correct subject.
  • A concern about the trade-offs if = multiple event types are expressed, should they share a common top-level = attribute. How does this improve or complicate multi-type events? =  In the draft, note that Figure 1 shows an event with a localized = extension that adds value without impacting inter-op.
  • =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in = the top-level. We=E2=80=99ve been discussing that additional attributes = should be in the payload. Item 3 shows sid in the payload. Which is = correct?

=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D

A.  We could = say that all SETs must embed sub and iss (if they use iss for = identifying subjects) in the payload.  See example 3 above. =  This would exclude options 1 and 2 and at least make it consistent = that subject information is always in the payload.  

B. A new top-level = attribute could be defined which is a JSON object. Inside the JSON = object, profiling specs can define how their subjects are addressed. = Let=E2=80=99s call it target.  A new common SET format might look = something like:

{ 
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "aud": [
  =   "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",<= /div>
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  = "target":{
    "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",<= /font>
    "iss": "https://scim.example.com"
  },
  "events": {
    "urn:ietf:params:scim:event:passwordReset": { = }
  }
}

Here is an example modified = logout 
   {
  =     "iss": "https://server.example.com",
      "aud": "s6BhdRkqt3",
      "iat": = 1471566154,
    =   "jti": "bWJq=E2=80=9D,
      =E2=80=9Ctarget=E2=80=9D:{
        "sub": = "248289761001",
    =     "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D
      }
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": = {}
      }
   }

The above formats = address the following:

* Consistent structures
* Flexibility = for profiles to target differently but using a common = attribute
* Multiple event types share a common = target and must be compatible (not sure if this is a plus or = minus)
* No conflict around SET issuer vs subject = issuer
* SET is substantially different such that = existing access token and ID token code will reject consistently = (because sub is missing)
* target could also have = an attribute that indicates the target =E2=80=9Ctype=E2=80=9D such as = SCIM resource, OP subject, IPaddress, and so on.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_0F6D31CD-EB6B-4EC5-BEC4-80B2D4CE6FE4-- From nobody Thu Jun 22 10:53:58 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251E01293FF for ; Thu, 22 Jun 2017 10:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB3mZ5ybX2of for ; Thu, 22 Jun 2017 10:53:52 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781D112751F for ; Thu, 22 Jun 2017 10:53:52 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id m62so54612457itc.0 for ; Thu, 22 Jun 2017 10:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r6lbk8Ly9cFHVcBk6kApBDyH5IHCCuyRVey7xSQft4c=; b=gOlQvFOg0rrAkzN43UdnHqsdRa7mPbRiqIqxkfQ3KSZuQ5oOVujhQa92I3JQfU2cE5 QYigek4o91YkUc91SiZC7j4QLw1B0NT/DHPc3pvFzNAcssIabfY0mjPzPSe5mS1oojsF dzv/4DZSBhcOd+O5Q9A7+oPDArq4h1vwdLniCTHkuCtQa9D3GQyntJNY5y0JH6ckIJ8u DnPg85G37chrps2952COkwZGgkkb2v1kukuFoKcz76k2v/DskNaFlGZC7AOJpsQg5GlM /wBSq9gegOcAy1uv3/DDSESYbuzSMxD9Buh2/bpba+DI257hUA9a/JHTiftlN/TSM0jB r8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r6lbk8Ly9cFHVcBk6kApBDyH5IHCCuyRVey7xSQft4c=; b=lhfrnoi1lbag7FtypqpTXQrw6NPZCy4Mtt+ZFTifzJhHghaXU02yHUg9+itfHij5od SmPQS3RXTKJk0TgTo6Zcd4FHe5KMAvb3YpSwoLakGjo2kd3sWoee88//6y/uOSrL2uZc Xt2p6oLEIkZRRQErClV4WeErzC8aeCP32ozoCxmTt7OO0wIeMBKynWkQ5S9BZd6iw73k a55Dq57htUHy5YYZPV5lWWXRkB4BSiitPfSAm11is9i2eS/ROtNAEvAvVlqUjX2ow2hF Y7tsUsjpC+jzWJ3wZwrIYs/9PEHkYp3+pPJ8vYyXssOJbMsuRxjJtZlM/a3v7jRGyWs6 j2aw== X-Gm-Message-State: AKS2vOxCTiMpwQN9eCUk6S2/P4AP34QYq+25c7a00bfzqQwLiLOAkjSI mbnFs6bbufIigcqZ6t2Mpc3Ho95v5tL8 X-Received: by 10.36.160.75 with SMTP id o72mr3161196ite.119.1498154031507; Thu, 22 Jun 2017 10:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 22 Jun 2017 10:53:30 -0700 (PDT) In-Reply-To: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> From: Marius Scurtescu Date: Thu, 22 Jun 2017 10:53:30 -0700 Message-ID: To: Phil Hunt Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c03d38cde7cfa0552902af5" Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:53:56 -0000 --94eb2c03d38cde7cfa0552902af5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Phil, concrete examples are very useful. The top level "target" attribute is interesting, it reduces redundancy across events (when multiple events are present in one SET) but it is enforcing a single profile per SET. As you mention, not sure if this is good or bad. Also, not sure about the name of the attribute, "target", but I cannot come up with a better name. "target" sounds like "audience". We need something along with "events subject". Maybe simply nest the "iss", "sub" and other right under "events"? Here is one more example of a SET not using "sub". SETs between an email provider and an implicit RP would use the OIDC defined "email" attribute (or "phone_number"): { "iss": "https://rp.example.com", "aud": "s6BhdRkqt3", "iat": 1471566154, "jti": "bWJq", "events": { "http://schemas.openid.net/event/risc//account-disabled": { "reason": "hijacking", "email": "bob@example.com", } } } Marius On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt wrote: > We=E2=80=99ve had a long standing thread on how to handle use of =E2=80= =9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D > in SET. I=E2=80=99d like to give some examples that we can compare. > > Please add your comments. It would be good to reach some conclusion in th= e > next few days if we are going to change the draft for Prague. > > Thanks! > > Three current draft examples: > > 1. A SCIM Event looks like: > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://security.example.com", > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > "events": { > "urn:ietf:params:scim:event:passwordReset": { } > } > } > > > 2. An OP issued Backchannel Logout (single-sign-out) looks like: > > { > > "iss": "https://server.example.com", > "sub": "248289761001", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02", > "events": { > "http://schemas.openid.net/event/backchannel-logout": {} > } > } > > > 3. An RP issued Application Logout Looks like (different issuer): > > { > "iss": "https://rp.example.com", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "events": { > "http://schemas.openid.net/event/risc-logout": { > "sub": "248289761001", > "iss": "https://server.example.com=E2=80=9D, > > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > > } > } > } > > > I believe the concerns here are: > > > - Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsiste= nt and moves around. > - SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use i= ts own attribute > in the payload (introducing more variability). As long as =E2=80=9Csu= b=E2=80=9D is valid > to use in SET than profiling specs can redefine sub for their own > purposes. Is this good or bad? > - Those writing parsers have to be concerned that when they are > parsing a SET they need to know the role of the server OR they have to > fully parse the entire object to determine if they are looking at stru= cture > 2 or 3. IOW a lot of implementations have to always check for an embe= dded > =E2=80=9Ciss=E2=80=9D to be sure they have the correct subject. > - A concern about the trade-offs if multiple event types are > expressed, should they share a common top-level attribute. How does th= is > improve or complicate multi-type events? In the draft, note that Figu= re 1 > shows an event with a localized extension that adds value without impa= cting > inter-op. > - =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top-= level. We=E2=80=99ve > been discussing that additional attributes should be in the payload. I= tem 3 > shows sid in the payload. Which is correct? > > > =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D > > A. We could say that all SETs must embed sub and iss (if they use iss fo= r > identifying subjects) in the payload. See example 3 above. This would > exclude options 1 and 2 and at least make it consistent that subject > information is always in the payload. > > B. A new top-level attribute could be defined which is a JSON object. > Inside the JSON object, profiling specs can define how their subjects are > addressed. Let=E2=80=99s call it target. A new common SET format might l= ook > something like: > > { > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://security.example.com", > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], > "target":{ > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > "iss": "https://scim.example.com" > }, > "events": { > "urn:ietf:params:scim:event:passwordReset": { } > } > } > > Here is an example modified logout > { > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq=E2=80=9D, > =E2=80=9Ctarget=E2=80=9D:{ > "sub": "248289761001", > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D > } > "events": { > "http://schemas.openid.net/event/backchannel-logout": {} > } > } > > The above formats address the following: > > * Consistent structures > * Flexibility for profiles to target differently but using a common > attribute > * Multiple event types share a common target and must be compatible (not > sure if this is a plus or minus) > * No conflict around SET issuer vs subject issuer > * SET is substantially different such that existing access token and ID > token code will reject consistently (because sub is missing) > * target could also have an attribute that indicates the target =E2=80=9C= type=E2=80=9D > such as SCIM resource, OP subject, IPaddress, and so on. > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c03d38cde7cfa0552902af5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Phil, concrete examples are very useful.

The top level "target" attribute is interesting, it redu= ces redundancy across events (when multiple events are present in one SET) = but it is enforcing a single profile per SET.=C2=A0 As you mention, not sur= e if this is good or bad.

Also, not sure about the= name of the attribute, "target", but I cannot come up with a bet= ter name. "target" sounds like "audience". We need some= thing along with "events subject". Maybe simply nest the "is= s", "sub" and other right under "events"?

Here is one more example of a SET not using "sub"= ;. SETs between an email provider and an implicit RP would use the OIDC def= ined "email" attribute (or "phone_number"):
<= div>{
=C2=A0 =C2=A0"iss": "https://rp.example.com",
=C2=A0 =C2=A0"aud": "s6BhdRkqt3&= quot;,
=C2=A0 =C2=A0&q= uot;iat": 1471566154,
=C2=A0 =C2=A0"jti": "bWJq",
=C2=A0 =C2=A0"events": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"reason&qu= ot;: "hijacking",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"email": "bob@example.com",
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}
}


=


Mar= ius

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt = <phil.hunt@oracle.com> wrote:
We=E2=80=99ve had a long standin= g thread on how to handle use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2= =80=9D in SET.=C2=A0 I=E2=80=99d like to give some examples that we can com= pare.

Please add your comments. It would be good to reac= h some conclusion in the next few days if we are going to change the draft = for Prague.

Thanks!

Three c= urrent draft examples:

1. A SCIM Event looks like:=
{=C2=A0
=C2=A0 "jti": "3d0c3cf7= 97584bd193bd0fb1bd4e7d30",
=C2=A0 "iat": 1458496025,
=C2=A0 &qu= ot;iss": "https://security.examp= le.com", =C2=A0
=C2=A0 "aud": [
=C2=A0 ], =C2= =A0
=C2=A0= "events": {
=C2=A0 =C2=A0 "urn:ietf:params:scim:ev= ent:passwordReset": { }
=C2=A0 }
}

2. An OP issued Backchannel Logout (single-sign-out) look= s like:
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 "iss": "https://server.example.com",

3. An RP issued Application Logout Looks like (diffe= rent issuer):
{
=C2=A0=C2= =A0 "iss": "= ;https://rp.example.co= m",
=C2=A0=C2=A0 "aud": "s6BhdRkqt3",
=C2=A0=C2=A0 &qu= ot;iat": 1471566154,<= /div>
=C2=A0=C2=A0 "jti": "bWJq",
=C2=A0=C2=A0 "events": {<= /div>
=C2=A0=C2=A0 =C2=A0 =C2=A0 "sub": &= quot;248289761001",
=C2=A0=C2=A0 =C2=A0 =C2=A0 "iss": "https://server.example.com=E2= =80=9D,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0"sid":= "08a5019c-17e1-4977-8f42-65a12843ea02"
=C2=A0=C2=A0 =C2=A0 }
=C2=A0=C2=A0 }
}

I believe the concern= s here are:

  • Use of =E2=80=9Csub=E2=80=9D a= nd =E2=80=9Ciss=E2=80=9D is inconsistent and moves around. =C2=A0
  • S= CIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its own a= ttribute in the payload (introducing more variability).=C2=A0 As long as = =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can redef= ine sub for their own purposes.=C2=A0 Is this good or bad?
  • Those wr= iting parsers have to be concerned that when they are parsing a SET they ne= ed to know the role of the server OR they have to fully parse the entire ob= ject to determine if they are looking at structure 2 or 3.=C2=A0 IOW a lot = of implementations have to always check for an embedded =E2=80=9Ciss=E2=80= =9D to be sure they have the correct subject.
  • A concern about the t= rade-offs if multiple event types are expressed, should they share a common= top-level attribute. How does this improve or complicate multi-type events= ?=C2=A0 In the draft, note that Figure 1 shows an event with a localized ex= tension that adds value without impacting inter-op.
  • =E2=80=9Csid=E2= =80=9D in Figure 2 of the SET document is in the top-level. We=E2=80=99ve b= een discussing that additional attributes should be in the payload. Item 3 = shows sid in the payload. Which is correct?

<= div>=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D
A.=C2=A0 We could say that all SETs must embed sub and iss (if= they use iss for identifying subjects) in the payload.=C2=A0 See example 3= above.=C2=A0 This would exclude options 1 and 2 and at least make it consi= stent that subject information is always in the payload. =C2=A0
<= br>
B. A new top-level attribute could be defined which is a JSON= object. Inside the JSON object, profiling specs can define how their subje= cts are addressed. Let=E2=80=99s call it target.=C2=A0 A new common SET for= mat might look something like:

{=C2=A0
=C2=A0 "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",
=C2=A0 &qu= ot;iat": 1458496025,<= /div>
=C2=A0 "iss&= quot;: "htt= ps://security.example.com", =C2=A0
=C2=A0 "aud": [
=C2=A0 =C2=A0 "https= ://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
=C2=A0 ], =C2=A0
=C2=A0 "target= ":{
=C2=A0 = =C2=A0 "iss": &q= uot;https://scim.exa= mple.com"
=C2=A0 },=
=C2=A0 "events": {
=C2=A0 =C2=A0 "urn:iet= f:params:scim:event:passwordReset": { }
=C2=A0 }
}

Here is an example modified logout=C2=A0
The above formats address the following:

* Consistent structures
* Flexibility for profiles to targ= et differently but using a common attribute
* Multiple event type= s share a common target and must be compatible (not sure if this is a plus = or minus)
* No conflict around SET issuer vs subject issuer
=
* SET is substantially different such that existing access token and I= D token code will reject consistently (because sub is missing)
* = target could also have an attribute that indicates the target =E2=80=9Ctype= =E2=80=9D such as SCIM resource, OP subject, IPaddress, and so on.

Phil

Oracle Corporation, Identity= Cloud Services Architect & Standards
@independentid
www.independen= tid.com
phil.hunt@oracle.com


____________________________________________= ___
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--94eb2c03d38cde7cfa0552902af5-- From nobody Thu Jun 22 10:58:36 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B9127B5A for ; Thu, 22 Jun 2017 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzUqyrN8Ssrx for ; Thu, 22 Jun 2017 10:58:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F0D12751F for ; Thu, 22 Jun 2017 10:58:28 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5MHwQTK012769 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 17:58:27 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5MHwQWl021852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jun 2017 17:58:26 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5MHwO8d008441; Thu, 22 Jun 2017 17:58:25 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jun 2017 10:58:23 -0700 From: Phil Hunt Message-Id: <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C28F9EE-08F1-419E-8960-46A2EB3B8FAC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 22 Jun 2017 10:58:22 -0700 In-Reply-To: Cc: ID Events Mailing List To: Marius Scurtescu References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:58:34 -0000 --Apple-Mail=_7C28F9EE-08F1-419E-8960-46A2EB3B8FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agreed to all your comments. And yes, =E2=80=9Ctarget=E2=80=9D is not = the best name. Just can=E2=80=99t think of one at the moment. Thanks for the additional example. =20 Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 22, 2017, at 10:53 AM, Marius Scurtescu = wrote: >=20 > Thanks Phil, concrete examples are very useful. >=20 > The top level "target" attribute is interesting, it reduces redundancy = across events (when multiple events are present in one SET) but it is = enforcing a single profile per SET. As you mention, not sure if this is = good or bad. >=20 > Also, not sure about the name of the attribute, "target", but I cannot = come up with a better name. "target" sounds like "audience". We need = something along with "events subject". Maybe simply nest the "iss", = "sub" and other right under "events"? >=20 > Here is one more example of a SET not using "sub". SETs between an = email provider and an implicit RP would use the OIDC defined "email" = attribute (or "phone_number"): > { > "iss": "https://rp.example.com ", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "events": { > "http://schemas.openid.net/event/risc//account-disabled = ": { > "reason": "hijacking", > "email": "bob@example.com ", > } > } > } >=20 >=20 >=20 >=20 >=20 > Marius >=20 > On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt > wrote: > We=E2=80=99ve had a long standing thread on how to handle use of = =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET. I=E2=80=99d = like to give some examples that we can compare. >=20 > Please add your comments. It would be good to reach some conclusion in = the next few days if we are going to change the draft for Prague. >=20 > Thanks! >=20 > Three current draft examples: >=20 > 1. A SCIM Event looks like: >> {=20 >> "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> "iat": 1458496025, >> "iss": "https://security.example.com = ", =20 >> "aud": [ >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " >> ], =20 >> "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = ", >> "events": { >> "urn:ietf:params:scim:event:passwordReset": { } >> } >> } >=20 >=20 > 2. An OP issued Backchannel Logout (single-sign-out) looks like: >> { >> "iss": "https://server.example.com = ", >> "sub": "248289761001", >> "aud": "s6BhdRkqt3", >> "iat": 1471566154, >> "jti": "bWJq", >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02", >> "events": { >> "http://schemas.openid.net/event/backchannel-logout = ": {} >> } >> } >=20 >=20 > 3. An RP issued Application Logout Looks like (different issuer): >> { >> "iss": "https://rp.example.com ", >> "aud": "s6BhdRkqt3", >> "iat": 1471566154, >> "jti": "bWJq", >> "events": { >> "http://schemas.openid.net/event/risc-logout = ": { >> "sub": "248289761001", >> "iss": "https://server.example.com = =E2=80=9D, >> "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >> } >> } >> } >=20 >=20 > I believe the concerns here are: >=20 > Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent = and moves around. =20 > SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its = own attribute in the payload (introducing more variability). As long as = =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can = redefine sub for their own purposes. Is this good or bad? > Those writing parsers have to be concerned that when they are parsing = a SET they need to know the role of the server OR they have to fully = parse the entire object to determine if they are looking at structure 2 = or 3. IOW a lot of implementations have to always check for an embedded = =E2=80=9Ciss=E2=80=9D to be sure they have the correct subject. > A concern about the trade-offs if multiple event types are expressed, = should they share a common top-level attribute. How does this improve or = complicate multi-type events? In the draft, note that Figure 1 shows an = event with a localized extension that adds value without impacting = inter-op. > =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the = top-level. We=E2=80=99ve been discussing that additional attributes = should be in the payload. Item 3 shows sid in the payload. Which is = correct? >=20 > =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D >=20 > A. We could say that all SETs must embed sub and iss (if they use iss = for identifying subjects) in the payload. See example 3 above. This = would exclude options 1 and 2 and at least make it consistent that = subject information is always in the payload. =20 >=20 > B. A new top-level attribute could be defined which is a JSON object. = Inside the JSON object, profiling specs can define how their subjects = are addressed. Let=E2=80=99s call it target. A new common SET format = might look something like: >=20 > {=20 > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://security.example.com = ", =20 > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 = ", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 = " > ], =20 > "target":{ > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = ", > "iss": "https://scim.example.com " > }, > "events": { > "urn:ietf:params:scim:event:passwordReset": { } > } > } >=20 > Here is an example modified logout=20 > { > "iss": "https://server.example.com = ", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq=E2=80=9D, > =E2=80=9Ctarget=E2=80=9D:{ > "sub": "248289761001", > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D > } > "events": { > "http://schemas.openid.net/event/backchannel-logout = ": {} > } > } >=20 > The above formats address the following: >=20 > * Consistent structures > * Flexibility for profiles to target differently but using a common = attribute > * Multiple event types share a common target and must be compatible = (not sure if this is a plus or minus) > * No conflict around SET issuer vs subject issuer > * SET is substantially different such that existing access token and = ID token code will reject consistently (because sub is missing) > * target could also have an attribute that indicates the target = =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, IPaddress, and = so on. >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com = phil.hunt@o= racle.com >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_7C28F9EE-08F1-419E-8960-46A2EB3B8FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agreed to all your comments.  And yes, =E2=80=9Ctarget=E2=80= =9D is not the best name.  Just can=E2=80=99t think of one at the = moment.

Thanks for = the additional example.  


On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

Thanks Phil, concrete examples are very useful.

The top level "target" = attribute is interesting, it reduces redundancy across events (when = multiple events are present in one SET) but it is enforcing a single = profile per SET.  As you mention, not sure if this is good or = bad.

Also, not = sure about the name of the attribute, "target", but I cannot come up = with a better name. "target" sounds like "audience". We need something = along with "events subject". Maybe simply nest the "iss", "sub" and = other right under "events"?

Here is one more example of a SET not using "sub". SETs = between an email provider and an implicit RP would use the OIDC defined = "email" attribute (or "phone_number"):
{
   "iss": "https://rp.example.com",
   "aud": = "s6BhdRkqt3",
   "iat": 1471566154,
  =  "jti": "bWJq",
   "events": {
    =  "http://schemas.openid.net/event/risc//account-disabled": = {
       "reason": = "hijacking",
       "email": "bob@example.com",
     }
   }
}





Marius

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
We=E2=80=99ve had a long = standing thread on how to handle use of =E2=80=9Csub=E2=80=9D and = =E2=80=9Ciss=E2=80=9D in SET.  I=E2=80=99d like to give some = examples that we can compare.

Please add your comments. It would be good to reach some = conclusion in the next few days if we are going to change the draft for = Prague.

Thanks!

Three current draft examples:

1. A SCIM Event looks like:
{ 
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": = 1458496025,
  "iss": "https://security.example.com", =  
  "aud": = [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
  "events": {
    "urn:ietf:params:scim:event:<= wbr class=3D"">passwordReset": { }
  }
}

2. An OP issued Backchannel Logout (single-sign-out) looks = like:
  =  {
      "iss": "https://server.example.com",
      "sub": = "248289761001",
    =   "aud": = "s6BhdRkqt3",
    =   "iat": = 1471566154,
    =   "jti": = "bWJq",
      "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

3. An RP issued = Application Logout Looks like (different issuer):
{
   "iss": "https://rp.example.com",
   "aud": = "s6BhdRkqt3",
   "iat": = 1471566154,
   "jti": = "bWJq",
   "events": {
     "http://schemas.openid.net/event/risc-logout": {
       "sub": = "248289761001",
   =     "iss": "https://server.example.com=E2=80=9D,
  =      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
     }
   }
}

I believe the concerns here = are:

  • Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2= =80=9D is inconsistent and moves around.  
  • SCIM = could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its own = attribute in the payload (introducing more variability).  As long = as =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can = redefine sub for their own purposes.  Is this good or bad?
  • Those writing parsers have to be concerned that when they are = parsing a SET they need to know the role of the server OR they have to = fully parse the entire object to determine if they are looking at = structure 2 or 3.  IOW a lot of implementations have to always = check for an embedded =E2=80=9Ciss=E2=80=9D to be sure they have the = correct subject.
  • A concern about the trade-offs if = multiple event types are expressed, should they share a common top-level = attribute. How does this improve or complicate multi-type events?  = In the draft, note that Figure 1 shows an event with a localized = extension that adds value without impacting inter-op.
  • =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in = the top-level. We=E2=80=99ve been discussing that additional attributes = should be in the payload. Item 3 shows sid in the payload. Which is = correct?

=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D

A.  We could = say that all SETs must embed sub and iss (if they use iss for = identifying subjects) in the payload.  See example 3 above.  = This would exclude options 1 and 2 and at least make it consistent that = subject information is always in the payload.  

B. A new top-level = attribute could be defined which is a JSON object. Inside the JSON = object, profiling specs can define how their subjects are addressed. = Let=E2=80=99s call it target.  A new common SET format might look = something like:

{ 
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": = 1458496025,
  "iss": "https://security.example.com", =  
  "aud": = [
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  "target":{
  =   "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
  =   "iss": "https://scim.example.com"
  },
  "events": {
    "urn:ietf:params:scim:event:<= wbr class=3D"">passwordReset": { }
  }
}

Here is an example modified = logout 
   {
  =     "iss": "https://server.example.com",
      "aud": = "s6BhdRkqt3",
    =   "iat": 1471566154,
      "jti": "bWJq=E2=80=9D,
      =E2=80=9Ctarget=E2=80=9D:{
        "sub": = "248289761001",
    =     "sid": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D
      }
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

The above formats address the = following:

* = Consistent structures
* Flexibility for profiles to = target differently but using a common attribute
* = Multiple event types share a common target and must be compatible (not = sure if this is a plus or minus)
* No conflict = around SET issuer vs subject issuer
* SET is = substantially different such that existing access token and ID token = code will reject consistently (because sub is missing)
* target could also have an attribute that indicates the = target =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, = IPaddress, and so on.

Phil

Oracle Corporation, Identity Cloud Services Architect & = Standards
@independentid
www.independentid.com
phil.hunt@oracle.com


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_7C28F9EE-08F1-419E-8960-46A2EB3B8FAC-- From nobody Thu Jun 22 12:45:24 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2735129B5C for ; Thu, 22 Jun 2017 12:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6eUUGsHG9il for ; Thu, 22 Jun 2017 12:45:16 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0112.outbound.protection.outlook.com [104.47.32.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88562129B4F for ; Thu, 22 Jun 2017 12:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sznq4bHzWCzHRpA2962Mu8TwSAwwqxgeKmPktTweNpo=; b=VkGPzaVHtGIf09xYRT589Hwt1ef4RSigu7KIMlGfsQ5gwYtoiTgXilWc6Dls+8zeUFRWXbG4z1AT6I7mWKspueARezfKO2qdVteLn23nMegI8LBbCTyilJHlvfMAoEIqYTfY13JNvH7+J5T5a8hRCmkzbXxdIEVVmugcFwmleL4= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0134.namprd21.prod.outlook.com (10.173.189.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.1; Thu, 22 Jun 2017 19:45:14 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.006; Thu, 22 Jun 2017 19:45:14 +0000 From: Mike Jones To: Phil Hunt , Marius Scurtescu CC: ID Events Mailing List Thread-Topic: [Id-event] Current vs. alternative subject exammples for SEC Token Draft Thread-Index: AQHS63m2mfqqQ9kkEEyBgFDpAXlpc6IxKfYAgAABXACAABuHIA== Date: Thu, 22 Jun 2017 19:45:14 +0000 Message-ID: References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> In-Reply-To: <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-22T14:45:05.2884363-05:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [64.134.170.73] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0134; 7:acN0J55+DFNmNTZAitc7k3xxv3s9baApU/p/v8zCim6pEQQsvK7qUln0lJjbo5n37Bi+gEaAQt9swRXiW/L7HNZ50zt292fDn4JioOuAfH67e9R7liUmhSDpYFVgdWxcbXJdN3wO1CW3fItY413rIYeTByCIUV+DoRvqRxnXBiMXzws+gBjwSUb2MlQwYL3ZrT6GkHlKSNoSYUqDEKdeVIMh7Fl/hxFGSiczNLyimz1HLoQfZIpFrIlCRAv3DxXEPvczZKtc7QO+Wh7T0sjZ5Wa0X00QfxTabFq6Df9gC/ul3z+36B6oORTLxgTuo2Jwo3J6JWpip+3gmilg2ntTwMZnR1lMnTehpSVIgtan9wNP2TCunvjGq4RJPj8ICtf/9t7gkQl8dlvzqAxT6Og0C574/WSj2L3OOL83fJk/kZRq1YT5xXzD0iGW4Ny1zZl+8Ytt8EIicUKEQFoU/FaxvmC68nIYD3nKliDRRjA02fbKIfeKHnXCZ5oi+BszOiSWvckTnAf2e/E+psD4i1U17l+yaXCg73Ht/qK+GSuPFkICTnBqSJC0RzqLsX3a0k4J9vUON/j7ob5AUcXVUIxYbJeLDVsLR+Ga1nCua3AgLh5ly0ZcAUEruUURQEzANibtkX2PmQSBihA5EMHzX3aAuksw1IFA7d62f9UWAvkV3eA6DZ27SfxACtmBfIPpNvNOJKhb/RioiiwdLcB9KhHuu08O+IUFkhEzSqINLAfWpPms9YETm100UjXV3fvmbfQ76T2TWS/EzECwhmQXyK2Emvj03AKm7UnqudLGXUZWnBBdiro0swbV28/2VZ4IPC1t x-ms-office365-filtering-correlation-id: 0ffa9a2f-44d2-40bf-ac68-08d4b9a733be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:CY4PR21MB0134; x-ms-traffictypediagnostic: CY4PR21MB0134: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(211936372134217)(21748063052155)(146099531331640)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0134; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0134; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39400400002)(39450400003)(39860400002)(39840400002)(51914003)(377454003)(24454002)(19609705001)(74316002)(575784001)(81166006)(77096006)(122556002)(3660700001)(54356999)(3280700002)(2900100001)(76176999)(551544002)(2950100002)(50986999)(33656002)(53946003)(2906002)(236005)(229853002)(6306002)(53546010)(54896002)(86362001)(189998001)(9686003)(606005)(55016002)(6436002)(6506006)(1680700002)(38730400002)(53386004)(8936002)(10290500003)(6116002)(5660300001)(102836003)(7736002)(4326008)(790700001)(66066001)(25786009)(478600001)(966005)(99286003)(5005710100001)(8676002)(14454004)(72206003)(3846002)(10090500001)(7906003)(53936002)(7696004)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0134; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB050453C8425C80321411AE3CF5DB0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 19:45:14.3643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0134 Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 19:45:23 -0000 --_000_CY4PR21MB050453C8425C80321411AE3CF5DB0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdG8gbWUgdGhhdCBtb3N0IG9mIHRoZSBkaXNjdXNzaW9ucyBtb3RpdmluZyB0aGUg cHJvcG9zYWxzIGJlaW5nIG1hZGUgaGF2ZSBiZWVuIGltcGxpY2l0bHkgYXNzdW1pbmcgdGhhdCBT RVRzIGFyZSBhYm91dCBkaWdpdGFsIGlkZW50aXRpZXMuICBJbiBtYW55IG9mIG91ciB1c2UgY2Fz ZXMsIHRoZXkgd2lsbCBiZSwgd2hpY2ggaXMgZ3JlYXQuICBJIGZ1bGx5IHN1cHBvcnQgc3RydWN0 aW5nIGV2ZW50cyBmb3IgaWRlbnRpdHkgcHJvZmlsZXMgdG8gbWVldCB0aGUgbmVlZHMgb2YgdGhv c2UgdXNlIGNhc2VzLCBpbmNsdWRpbmcgb2Z0ZW4gaGF2aW5nIGEgZGlzdGluY3QgU0VUIGlzc3Vl ciBmcm9tIHRoZSBkaWdpdGFsIGlkZW50aXR5IOKAnGlzc+KAnSB2YWx1ZSBhbmQgaGF2aW5nIGl0 IGFuZCB0aGUgZGlnaXRhbCBpZGVudGl0eSDigJxzdWLigJ0gYmUgaW4gdGhlIGV2ZW50IHN0cnVj dHVyZSwgd2hlbiBuZWVkZWQuDQoNCkJ1dCBqdXN0IGxpa2UgSldUcyBhcmUgZ3JlYXQgZm9yIGRp Z2l0YWwgaWRlbnRpdGllcyAoY29uc2lkZXIgSUQgVG9rZW5zKSBidXQgYXJlIHVzZWQgaW4gY29t cGxldGVseSB1bnJlbGF0ZWQgd2F5cyBhcyB3ZWxsIChzdWNoIGFzIENhbGxlci1JRCBzdGFuZGFy ZHMpLCBTRVRzIHNob3VsZCBiZSBncmVhdCBmb3IgZGlnaXRhbCBpZGVudGl0aWVzIChjb25zaWRl ciBSSVNDIGFuZCBTQ0lNIHByb2ZpbGVzKSBidXQgYWxzbyBiZSBncmVhdCBmb3IgdW5yZWxhdGVk IHVzZSBjYXNlcy4NCg0KSW4gc29tZSB1c2UgY2FzZXMgdGhlcmUgd2lsbCBiZSBvbmx5IG9uZSDi gJxpc3PigJ0gYW5kIHRoZSDigJxzdWLigJ0gbWF5IGJlIHZlcnkgZGlmZmVyZW50IGZyb20gdGhv c2Ugd2UgdXNlIGZvciBpZGVudGl0aWVzLiAgV2Ugd291bGQgYmUgZG9pbmcgZXZlcnlvbmUgYSBk aXNzZXJ2aWNlIHRvIG1hbnkgdXNlIGNhc2VzIGlmIHdlIHRyaWVkIHRvIGZvcmNlIHRoYXQg4oCc c3Vi4oCdIGFuZCDigJxpc3PigJ0gYmUgcHJlc2VudCBhdCB0aGUgZXZlbnQgbGV2ZWwsIHdoZW4g dGhvc2UgcHJvZmlsZXMgZG9u4oCZdCBuZWVkIGl0IHRoZXJlLg0KDQpXZSBzaG91bGRu4oCZdCBt YWtlIGV2ZXJ5IFNFVCB1c2UgbW9yZSBjb21wbGljYXRlZCBzeW50YXggdGhhdCBvbmx5IG1vcmUg YWR2YW5jZWQgdXNlIGNhc2VzIGFjdHVhbGx5IG5lZWQuICBUaGVyZWZvcmUsIHdlIHNob3VsZCBs ZWF2ZSB0aGUg4oCcc3Vi4oCdIGFuZCBvdGhlciBjbGFpbXMgZGVzY3JpcHRpb25zIGFzIHRoZXkg YXJlLiAgUmlnaHQgbm93IGl04oCZcyBnZW5lcmFsIHB1cnBvc2UgYW5kIHNpbXBsZS4gIExldOKA mXMgbm90IG5lZWRsZXNzbHkgYnJlYWsgdGhhdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQg W21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbCBIdW50 DQpTZW50OiBUaHVyc2RheSwgSnVuZSAyMiwgMjAxNyAxMjo1OCBQTQ0KVG86IE1hcml1cyBTY3Vy dGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0 IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIEN1cnJlbnQgdnMu IGFsdGVybmF0aXZlIHN1YmplY3QgZXhhbW1wbGVzIGZvciBTRUMgVG9rZW4gRHJhZnQNCg0KQWdy ZWVkIHRvIGFsbCB5b3VyIGNvbW1lbnRzLiAgQW5kIHllcywg4oCcdGFyZ2V04oCdIGlzIG5vdCB0 aGUgYmVzdCBuYW1lLiAgSnVzdCBjYW7igJl0IHRoaW5rIG9mIG9uZSBhdCB0aGUgbW9tZW50Lg0K DQpUaGFua3MgZm9yIHRoZSBhZGRpdGlvbmFsIGV4YW1wbGUuDQoNClBoaWwNCg0KT3JhY2xlIENv cnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QgJiBTdGFuZGFyZHMN CkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbT4NCg0KT24gSnVuIDIyLCAyMDE3LCBhdCAxMDo1MyBBTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8 bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiB3cm90 ZToNCg0KVGhhbmtzIFBoaWwsIGNvbmNyZXRlIGV4YW1wbGVzIGFyZSB2ZXJ5IHVzZWZ1bC4NCg0K VGhlIHRvcCBsZXZlbCAidGFyZ2V0IiBhdHRyaWJ1dGUgaXMgaW50ZXJlc3RpbmcsIGl0IHJlZHVj ZXMgcmVkdW5kYW5jeSBhY3Jvc3MgZXZlbnRzICh3aGVuIG11bHRpcGxlIGV2ZW50cyBhcmUgcHJl c2VudCBpbiBvbmUgU0VUKSBidXQgaXQgaXMgZW5mb3JjaW5nIGEgc2luZ2xlIHByb2ZpbGUgcGVy IFNFVC4gIEFzIHlvdSBtZW50aW9uLCBub3Qgc3VyZSBpZiB0aGlzIGlzIGdvb2Qgb3IgYmFkLg0K DQpBbHNvLCBub3Qgc3VyZSBhYm91dCB0aGUgbmFtZSBvZiB0aGUgYXR0cmlidXRlLCAidGFyZ2V0 IiwgYnV0IEkgY2Fubm90IGNvbWUgdXAgd2l0aCBhIGJldHRlciBuYW1lLiAidGFyZ2V0IiBzb3Vu ZHMgbGlrZSAiYXVkaWVuY2UiLiBXZSBuZWVkIHNvbWV0aGluZyBhbG9uZyB3aXRoICJldmVudHMg c3ViamVjdCIuIE1heWJlIHNpbXBseSBuZXN0IHRoZSAiaXNzIiwgInN1YiIgYW5kIG90aGVyIHJp Z2h0IHVuZGVyICJldmVudHMiPw0KDQpIZXJlIGlzIG9uZSBtb3JlIGV4YW1wbGUgb2YgYSBTRVQg bm90IHVzaW5nICJzdWIiLiBTRVRzIGJldHdlZW4gYW4gZW1haWwgcHJvdmlkZXIgYW5kIGFuIGlt cGxpY2l0IFJQIHdvdWxkIHVzZSB0aGUgT0lEQyBkZWZpbmVkICJlbWFpbCIgYXR0cmlidXRlIChv ciAicGhvbmVfbnVtYmVyIik6DQp7DQogICAiaXNzIjogImh0dHBzOi8vcnAuZXhhbXBsZS5jb208 aHR0cHM6Ly9ycC5leGFtcGxlLmNvbS8+IiwNCiAgICJhdWQiOiAiczZCaGRSa3F0MyIsDQogICAi aWF0IjogMTQ3MTU2NjE1NCwNCiAgICJqdGkiOiAiYldKcSIsDQogICAiZXZlbnRzIjogew0KICAg ICAiaHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9ldmVudC9yaXNjLy9hY2NvdW50LWRpc2FibGVk PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hl bWFzLm9wZW5pZC5uZXRfZXZlbnRfcmlzY19fYWNjb3VudC0yRGRpc2FibGVkJmQ9RHdNRmFRJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1nNUU4bC1IWWpNaXU2NkpnLUZkZTFj QmczNlg3VHV1SHA4ZHhKN3NTWXlrJnM9Ylp4X25oYVJlN0NDYVIxWTBFSWlweEg4UnFXQ1dEb0JP NF9tZnZtZnlFVSZlPT4iOiB7DQogICAgICAgInJlYXNvbiI6ICJoaWphY2tpbmciLA0KICAgICAg ICJlbWFpbCI6ICJib2JAZXhhbXBsZS5jb208bWFpbHRvOmJvYkBleGFtcGxlLmNvbT4iLA0KICAg ICB9DQogICB9DQp9DQoNCg0KDQoNCg0KTWFyaXVzDQoNCk9uIFRodSwgSnVuIDIyLCAyMDE3IGF0 IDEwOjA1IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KV2XigJl2ZSBoYWQgYSBsb25nIHN0YW5kaW5nIHRocmVh ZCBvbiBob3cgdG8gaGFuZGxlIHVzZSBvZiDigJxzdWLigJ0gYW5kIOKAnGlzc+KAnSBpbiBTRVQu ICBJ4oCZZCBsaWtlIHRvIGdpdmUgc29tZSBleGFtcGxlcyB0aGF0IHdlIGNhbiBjb21wYXJlLg0K DQpQbGVhc2UgYWRkIHlvdXIgY29tbWVudHMuIEl0IHdvdWxkIGJlIGdvb2QgdG8gcmVhY2ggc29t ZSBjb25jbHVzaW9uIGluIHRoZSBuZXh0IGZldyBkYXlzIGlmIHdlIGFyZSBnb2luZyB0byBjaGFu Z2UgdGhlIGRyYWZ0IGZvciBQcmFndWUuDQoNClRoYW5rcyENCg0KVGhyZWUgY3VycmVudCBkcmFm dCBleGFtcGxlczoNCg0KMS4gQSBTQ0lNIEV2ZW50IGxvb2tzIGxpa2U6DQp7DQogICJqdGkiOiAi M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAiLA0KICAiaWF0IjogMTQ1ODQ5NjAyNSwN CiAgImlzcyI6ICJodHRwczovL3NlY3VyaXR5LmV4YW1wbGUuY29tPGh0dHBzOi8vc2VjdXJpdHku ZXhhbXBsZS5jb20vPiIsDQogICJhdWQiOiBbDQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNv bS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0IiwNCiAgICAiaHR0cHM6Ly9qaHViLmV4 YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciDQogIF0sDQogICJzdWIi OiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIx ZDkiLA0KICAiZXZlbnRzIjogew0KICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNz d29yZFJlc2V0IjogeyB9DQogIH0NCn0NCg0KMi4gQW4gT1AgaXNzdWVkIEJhY2tjaGFubmVsIExv Z291dCAoc2luZ2xlLXNpZ24tb3V0KSBsb29rcyBsaWtlOg0KICAgew0KICAgICAgImlzcyI6ICJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbTxodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8+IiwN CiAgICAgICJzdWIiOiAiMjQ4Mjg5NzYxMDAxIiwNCiAgICAgICJhdWQiOiAiczZCaGRSa3F0MyIs DQogICAgICAiaWF0IjogMTQ3MTU2NjE1NCwNCiAgICAgICJqdGkiOiAiYldKcSIsDQogICAgICAi c2lkIjogIjA4YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1YTEyODQzZWEwMiIsDQogICAgICAiZXZl bnRzIjogew0KICAgICAgICAiaHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9ldmVudC9iYWNrY2hh bm5lbC1sb2dvdXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9ldmVudF9iYWNrY2hhbm5lbC0yRGxvZ291dCZkPUR3 TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09ZzVFOGwtSFlqTWl1NjZK Zy1GZGUxY0JnMzZYN1R1dUhwOGR4SjdzU1l5ayZzPVJnUXdIMjNzNXdZcDBzakxsQVNJZE5YcHB1 WmthZEdwMi0yN1AyZFhvQlEmZT0+Ijoge30NCiAgICAgIH0NCiAgIH0NCg0KMy4gQW4gUlAgaXNz dWVkIEFwcGxpY2F0aW9uIExvZ291dCBMb29rcyBsaWtlIChkaWZmZXJlbnQgaXNzdWVyKToNCnsN CiAgICJpc3MiOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbTxodHRwczovL3JwLmV4YW1wbGUuY29t Lz4iLA0KICAgImF1ZCI6ICJzNkJoZFJrcXQzIiwNCiAgICJpYXQiOiAxNDcxNTY2MTU0LA0KICAg Imp0aSI6ICJiV0pxIiwNCiAgICJldmVudHMiOiB7DQogICAgICJodHRwOi8vc2NoZW1hcy5vcGVu aWQubmV0L2V2ZW50L3Jpc2MtbG9nb3V0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfZXZlbnRfcmlzYy0yRGxvZ291 dCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09ZzVFOGwtSFlq TWl1NjZKZy1GZGUxY0JnMzZYN1R1dUhwOGR4SjdzU1l5ayZzPUJ6Vk4zOHhST3NDczFTdlpsQm5U bXh4QlZxMExoX3BzOTdQNWNZRTdxWDQmZT0+Ijogew0KICAgICAgICJzdWIiOiAiMjQ4Mjg5NzYx MDAxIiwNCiAgICAgICAiaXNzIjogImh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tPGh0dHBzOi8v c2VydmVyLmV4YW1wbGUuY29tLz7igJ0sDQogICAgICAgInNpZCI6ICIwOGE1MDE5Yy0xN2UxLTQ5 NzctOGY0Mi02NWExMjg0M2VhMDIiDQogICAgIH0NCiAgIH0NCn0NCg0KSSBiZWxpZXZlIHRoZSBj b25jZXJucyBoZXJlIGFyZToNCg0KDQogICogICBVc2Ugb2Yg4oCcc3Vi4oCdIGFuZCDigJxpc3Pi gJ0gaXMgaW5jb25zaXN0ZW50IGFuZCBtb3ZlcyBhcm91bmQuDQogICogICBTQ0lNIGNvdWxkIHJl ZGVmaW5lIOKAnHN1YuKAnSBhcyBhIFVSSSBvciBpdCBjb3VsZCB1c2UgaXRzIG93biBhdHRyaWJ1 dGUgaW4gdGhlIHBheWxvYWQgKGludHJvZHVjaW5nIG1vcmUgdmFyaWFiaWxpdHkpLiAgQXMgbG9u ZyBhcyDigJxzdWLigJ0gaXMgdmFsaWQgdG8gdXNlIGluIFNFVCB0aGFuIHByb2ZpbGluZyBzcGVj cyBjYW4gcmVkZWZpbmUgc3ViIGZvciB0aGVpciBvd24gcHVycG9zZXMuICBJcyB0aGlzIGdvb2Qg b3IgYmFkPw0KICAqICAgVGhvc2Ugd3JpdGluZyBwYXJzZXJzIGhhdmUgdG8gYmUgY29uY2VybmVk IHRoYXQgd2hlbiB0aGV5IGFyZSBwYXJzaW5nIGEgU0VUIHRoZXkgbmVlZCB0byBrbm93IHRoZSBy b2xlIG9mIHRoZSBzZXJ2ZXIgT1IgdGhleSBoYXZlIHRvIGZ1bGx5IHBhcnNlIHRoZSBlbnRpcmUg b2JqZWN0IHRvIGRldGVybWluZSBpZiB0aGV5IGFyZSBsb29raW5nIGF0IHN0cnVjdHVyZSAyIG9y IDMuICBJT1cgYSBsb3Qgb2YgaW1wbGVtZW50YXRpb25zIGhhdmUgdG8gYWx3YXlzIGNoZWNrIGZv ciBhbiBlbWJlZGRlZCDigJxpc3PigJ0gdG8gYmUgc3VyZSB0aGV5IGhhdmUgdGhlIGNvcnJlY3Qg c3ViamVjdC4NCiAgKiAgIEEgY29uY2VybiBhYm91dCB0aGUgdHJhZGUtb2ZmcyBpZiBtdWx0aXBs ZSBldmVudCB0eXBlcyBhcmUgZXhwcmVzc2VkLCBzaG91bGQgdGhleSBzaGFyZSBhIGNvbW1vbiB0 b3AtbGV2ZWwgYXR0cmlidXRlLiBIb3cgZG9lcyB0aGlzIGltcHJvdmUgb3IgY29tcGxpY2F0ZSBt dWx0aS10eXBlIGV2ZW50cz8gIEluIHRoZSBkcmFmdCwgbm90ZSB0aGF0IEZpZ3VyZSAxIHNob3dz IGFuIGV2ZW50IHdpdGggYSBsb2NhbGl6ZWQgZXh0ZW5zaW9uIHRoYXQgYWRkcyB2YWx1ZSB3aXRo b3V0IGltcGFjdGluZyBpbnRlci1vcC4NCiAgKiAgIOKAnHNpZOKAnSBpbiBGaWd1cmUgMiBvZiB0 aGUgU0VUIGRvY3VtZW50IGlzIGluIHRoZSB0b3AtbGV2ZWwuIFdl4oCZdmUgYmVlbiBkaXNjdXNz aW5nIHRoYXQgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHNob3VsZCBiZSBpbiB0aGUgcGF5bG9hZC4g SXRlbSAzIHNob3dzIHNpZCBpbiB0aGUgcGF5bG9hZC4gV2hpY2ggaXMgY29ycmVjdD8NCg0KPT09 PT09PVBvc3NpYmxlIE9wdGlvbnM9PT09PT09DQoNCkEuICBXZSBjb3VsZCBzYXkgdGhhdCBhbGwg U0VUcyBtdXN0IGVtYmVkIHN1YiBhbmQgaXNzIChpZiB0aGV5IHVzZSBpc3MgZm9yIGlkZW50aWZ5 aW5nIHN1YmplY3RzKSBpbiB0aGUgcGF5bG9hZC4gIFNlZSBleGFtcGxlIDMgYWJvdmUuICBUaGlz IHdvdWxkIGV4Y2x1ZGUgb3B0aW9ucyAxIGFuZCAyIGFuZCBhdCBsZWFzdCBtYWtlIGl0IGNvbnNp c3RlbnQgdGhhdCBzdWJqZWN0IGluZm9ybWF0aW9uIGlzIGFsd2F5cyBpbiB0aGUgcGF5bG9hZC4N Cg0KQi4gQSBuZXcgdG9wLWxldmVsIGF0dHJpYnV0ZSBjb3VsZCBiZSBkZWZpbmVkIHdoaWNoIGlz IGEgSlNPTiBvYmplY3QuIEluc2lkZSB0aGUgSlNPTiBvYmplY3QsIHByb2ZpbGluZyBzcGVjcyBj YW4gZGVmaW5lIGhvdyB0aGVpciBzdWJqZWN0cyBhcmUgYWRkcmVzc2VkLiBMZXTigJlzIGNhbGwg aXQgdGFyZ2V0LiAgQSBuZXcgY29tbW9uIFNFVCBmb3JtYXQgbWlnaHQgbG9vayBzb21ldGhpbmcg bGlrZToNCg0Kew0KICAianRpIjogIjNkMGMzY2Y3OTc1ODRiZDE5M2JkMGZiMWJkNGU3ZDMwIiwN CiAgImlhdCI6IDE0NTg0OTYwMjUsDQogICJpc3MiOiAiaHR0cHM6Ly9zZWN1cml0eS5leGFtcGxl LmNvbTxodHRwczovL3NlY3VyaXR5LmV4YW1wbGUuY29tLz4iLA0KICAiYXVkIjogWw0KICAgICJo dHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIs DQogICAgImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3 Njc2ZWU3Ig0KICBdLA0KICAidGFyZ2V0Ijp7DQogICAgInN1YiI6ICJodHRwczovL3NjaW0uZXhh bXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsDQogICAgImlzcyI6ICJo dHRwczovL3NjaW0uZXhhbXBsZS5jb208aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tLz4iDQogIH0s DQogICJldmVudHMiOiB7DQogICAgInVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50OnBhc3N3b3Jk UmVzZXQiOiB7IH0NCiAgfQ0KfQ0KDQpIZXJlIGlzIGFuIGV4YW1wbGUgbW9kaWZpZWQgbG9nb3V0 DQogICB7DQogICAgICAiaXNzIjogImh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tPGh0dHBzOi8v c2VydmVyLmV4YW1wbGUuY29tLz4iLA0KICAgICAgImF1ZCI6ICJzNkJoZFJrcXQzIiwNCiAgICAg ICJpYXQiOiAxNDcxNTY2MTU0LA0KICAgICAgImp0aSI6ICJiV0px4oCdLA0KICAgICAg4oCcdGFy Z2V04oCdOnsNCiAgICAgICAgInN1YiI6ICIyNDgyODk3NjEwMDEiLA0KICAgICAgICAic2lkIjog IjA4YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1YTEyODQzZWEwMuKAnQ0KICAgICAgfQ0KICAgICAg ImV2ZW50cyI6IHsNCiAgICAgICAgImh0dHA6Ly9zY2hlbWFzLm9wZW5pZC5uZXQvZXZlbnQvYmFj a2NoYW5uZWwtbG9nb3V0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfZXZlbnRfYmFja2NoYW5uZWwtMkRsb2dvdXQm ZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9 SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPWc1RThsLUhZak1p dTY2SmctRmRlMWNCZzM2WDdUdXVIcDhkeEo3c1NZeWsmcz1SZ1F3SDIzczV3WXAwc2pMbEFTSWRO WHBwdVprYWRHcDItMjdQMmRYb0JRJmU9PiI6IHt9DQogICAgICB9DQogICB9DQoNClRoZSBhYm92 ZSBmb3JtYXRzIGFkZHJlc3MgdGhlIGZvbGxvd2luZzoNCg0KKiBDb25zaXN0ZW50IHN0cnVjdHVy ZXMNCiogRmxleGliaWxpdHkgZm9yIHByb2ZpbGVzIHRvIHRhcmdldCBkaWZmZXJlbnRseSBidXQg dXNpbmcgYSBjb21tb24gYXR0cmlidXRlDQoqIE11bHRpcGxlIGV2ZW50IHR5cGVzIHNoYXJlIGEg Y29tbW9uIHRhcmdldCBhbmQgbXVzdCBiZSBjb21wYXRpYmxlIChub3Qgc3VyZSBpZiB0aGlzIGlz IGEgcGx1cyBvciBtaW51cykNCiogTm8gY29uZmxpY3QgYXJvdW5kIFNFVCBpc3N1ZXIgdnMgc3Vi amVjdCBpc3N1ZXINCiogU0VUIGlzIHN1YnN0YW50aWFsbHkgZGlmZmVyZW50IHN1Y2ggdGhhdCBl eGlzdGluZyBhY2Nlc3MgdG9rZW4gYW5kIElEIHRva2VuIGNvZGUgd2lsbCByZWplY3QgY29uc2lz dGVudGx5IChiZWNhdXNlIHN1YiBpcyBtaXNzaW5nKQ0KKiB0YXJnZXQgY291bGQgYWxzbyBoYXZl IGFuIGF0dHJpYnV0ZSB0aGF0IGluZGljYXRlcyB0aGUgdGFyZ2V0IOKAnHR5cGXigJ0gc3VjaCBh cyBTQ0lNIHJlc291cmNlLCBPUCBzdWJqZWN0LCBJUGFkZHJlc3MsIGFuZCBzbyBvbi4NCg0KUGhp bA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVj dCAmIFN0YW5kYXJkcw0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVw ZW5kZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm bT1nNUU4bC1IWWpNaXU2NkpnLUZkZTFjQmczNlg3VHV1SHA4ZHhKN3NTWXlrJnM9Vk92MWItNzZq YkdPdnBFR09fTy1LOWcxaERwQnpNM3dRa1B0TEtQYVNWUSZlPT4NCnBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1l dmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09 ZzVFOGwtSFlqTWl1NjZKZy1GZGUxY0JnMzZYN1R1dUhwOGR4SjdzU1l5ayZzPXE1RktHdEUzaUdT NFgteThLNnl0aDRBbjI0Y1BaeVZYcE5OZE1QQThyd1UmZT0+DQoNCg== --_000_CY4PR21MB050453C8425C80321411AE3CF5DB0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5Ok1vbmFjbzsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5 bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tODQzMDMwMTI2NTYyNzExODEy NGFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6bV84NDMwMzAxMjY1NjI3MTE4MTI0 YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjEyMDg0NDg1Nzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05 MDUxNDA3OTQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SXQgc2Vl bXMgdG8gbWUgdGhhdCBtb3N0IG9mIHRoZSBkaXNjdXNzaW9ucyBtb3RpdmluZyB0aGUgcHJvcG9z YWxzIGJlaW5nIG1hZGUgaGF2ZSBiZWVuIGltcGxpY2l0bHkgYXNzdW1pbmcgdGhhdCBTRVRzIGFy ZSBhYm91dCBkaWdpdGFsIGlkZW50aXRpZXMuJm5ic3A7IEluIG1hbnkgb2Ygb3VyIHVzZSBjYXNl cywgdGhleSB3aWxsIGJlLCB3aGljaCBpcyBncmVhdC4mbmJzcDsgSQ0KIGZ1bGx5IHN1cHBvcnQg c3RydWN0aW5nIGV2ZW50cyBmb3IgaWRlbnRpdHkgcHJvZmlsZXMgdG8gbWVldCB0aGUgbmVlZHMg b2YgdGhvc2UgdXNlIGNhc2VzLCBpbmNsdWRpbmcgb2Z0ZW4gaGF2aW5nIGEgZGlzdGluY3QgU0VU IGlzc3VlciBmcm9tIHRoZSBkaWdpdGFsIGlkZW50aXR5IOKAnGlzc+KAnSB2YWx1ZSBhbmQgaGF2 aW5nIGl0IGFuZCB0aGUgZGlnaXRhbCBpZGVudGl0eSDigJxzdWLigJ0gYmUgaW4gdGhlIGV2ZW50 IHN0cnVjdHVyZSwgd2hlbiBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj5CdXQganVzdCBsaWtlIEpXVHMgYXJlIGdyZWF0IGZvciBkaWdpdGFsIGlkZW50aXRpZXMg KGNvbnNpZGVyIElEIFRva2VucykgYnV0IGFyZSB1c2VkIGluIGNvbXBsZXRlbHkgdW5yZWxhdGVk IHdheXMgYXMgd2VsbCAoc3VjaCBhcyBDYWxsZXItSUQgc3RhbmRhcmRzKSwgU0VUcyBzaG91bGQg YmUgZ3JlYXQgZm9yIGRpZ2l0YWwgaWRlbnRpdGllcyAoY29uc2lkZXINCiBSSVNDIGFuZCBTQ0lN IHByb2ZpbGVzKSBidXQgYWxzbyBiZSBncmVhdCBmb3IgdW5yZWxhdGVkIHVzZSBjYXNlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkluIHNvbWUgdXNlIGNhc2VzIHRoZXJl IHdpbGwgYmUgb25seSBvbmUg4oCcaXNz4oCdIGFuZCB0aGUg4oCcc3Vi4oCdIG1heSBiZSB2ZXJ5 IGRpZmZlcmVudCBmcm9tIHRob3NlIHdlIHVzZSBmb3IgaWRlbnRpdGllcy4mbmJzcDsgV2Ugd291 bGQgYmUgZG9pbmcgZXZlcnlvbmUgYSBkaXNzZXJ2aWNlIHRvIG1hbnkgdXNlIGNhc2VzIGlmIHdl IHRyaWVkIHRvIGZvcmNlIHRoYXQg4oCcc3Vi4oCdDQogYW5kIOKAnGlzc+KAnSBiZSBwcmVzZW50 IGF0IHRoZSBldmVudCBsZXZlbCwgd2hlbiB0aG9zZSBwcm9maWxlcyBkb27igJl0IG5lZWQgaXQg dGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XZSBzaG91bGRu4oCZ dCBtYWtlIGV2ZXJ5IFNFVCB1c2UgbW9yZSBjb21wbGljYXRlZCBzeW50YXggdGhhdCBvbmx5IG1v cmUgYWR2YW5jZWQgdXNlIGNhc2VzIGFjdHVhbGx5IG5lZWQuICZuYnNwO1RoZXJlZm9yZSwgd2Ug c2hvdWxkIGxlYXZlIHRoZSDigJxzdWLigJ0gYW5kIG90aGVyIGNsYWltcyBkZXNjcmlwdGlvbnMg YXMgdGhleSBhcmUuJm5ic3A7IFJpZ2h0IG5vdyBpdOKAmXMgZ2VuZXJhbA0KIHB1cnBvc2UgYW5k IHNpbXBsZS4mbmJzcDsgTGV04oCZcyBub3QgbmVlZGxlc3NseSBicmVhayB0aGF0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWQtZXZlbnQgW21h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSA8Yj4NCk9uIEJlaGFsZiBPZiA8L2I+UGhp bCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDIyLCAyMDE3IDEyOjU4IFBN PGJyPg0KPGI+VG86PC9iPiBNYXJpdXMgU2N1cnRlc2N1ICZsdDttc2N1cnRlc2N1QGdvb2dsZS5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDtpZC1ldmVu dEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gQ3VycmVu dCB2cy4gYWx0ZXJuYXRpdmUgc3ViamVjdCBleGFtbXBsZXMgZm9yIFNFQyBUb2tlbiBEcmFmdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkIHRvIGFsbCB5b3Vy IGNvbW1lbnRzLiAmbmJzcDtBbmQgeWVzLCDigJx0YXJnZXTigJ0gaXMgbm90IHRoZSBiZXN0IG5h bWUuICZuYnNwO0p1c3QgY2Fu4oCZdCB0aGluayBvZiBvbmUgYXQgdGhlIG1vbWVudC48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGFk ZGl0aW9uYWwgZXhhbXBsZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PcmFjbGUgQ29ycG9yYXRp b24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdCAmYW1wOyBTdGFuZGFyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdW4g MjIsIDIwMTcsIGF0IDEwOjUzIEFNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWls dG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoYW5rcyBQaGlsLCBjb25jcmV0ZSBleGFtcGxlcyBhcmUgdmVyeSB1c2Vm dWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB0b3AgbGV2ZWwg JnF1b3Q7dGFyZ2V0JnF1b3Q7IGF0dHJpYnV0ZSBpcyBpbnRlcmVzdGluZywgaXQgcmVkdWNlcyBy ZWR1bmRhbmN5IGFjcm9zcyBldmVudHMgKHdoZW4gbXVsdGlwbGUgZXZlbnRzIGFyZSBwcmVzZW50 IGluIG9uZSBTRVQpIGJ1dCBpdCBpcyBlbmZvcmNpbmcgYSBzaW5nbGUgcHJvZmlsZSBwZXINCiBT RVQuJm5ic3A7IEFzIHlvdSBtZW50aW9uLCBub3Qgc3VyZSBpZiB0aGlzIGlzIGdvb2Qgb3IgYmFk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsc28sIG5v dCBzdXJlIGFib3V0IHRoZSBuYW1lIG9mIHRoZSBhdHRyaWJ1dGUsICZxdW90O3RhcmdldCZxdW90 OywgYnV0IEkgY2Fubm90IGNvbWUgdXAgd2l0aCBhIGJldHRlciBuYW1lLiAmcXVvdDt0YXJnZXQm cXVvdDsgc291bmRzIGxpa2UgJnF1b3Q7YXVkaWVuY2UmcXVvdDsuIFdlIG5lZWQgc29tZXRoaW5n IGFsb25nIHdpdGggJnF1b3Q7ZXZlbnRzIHN1YmplY3QmcXVvdDsuDQogTWF5YmUgc2ltcGx5IG5l c3QgdGhlICZxdW90O2lzcyZxdW90OywgJnF1b3Q7c3ViJnF1b3Q7IGFuZCBvdGhlciByaWdodCB1 bmRlciAmcXVvdDtldmVudHMmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SGVyZSBpcyBvbmUgbW9yZSBleGFtcGxlIG9mIGEgU0VUIG5vdCB1c2lu ZyAmcXVvdDtzdWImcXVvdDsuIFNFVHMgYmV0d2VlbiBhbiBlbWFpbCBwcm92aWRlciBhbmQgYW4g aW1wbGljaXQgUlAgd291bGQgdXNlIHRoZSBPSURDIGRlZmluZWQgJnF1b3Q7ZW1haWwmcXVvdDsg YXR0cmlidXRlIChvciAmcXVvdDtwaG9uZV9udW1iZXImcXVvdDspOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij57PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDsmcXVv dDtpc3MmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vcnAuZXhhbXBsZS5jb20vIj5odHRw czovL3JwLmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7ICZuYnNwOyZxdW90O2F1ZCZxdW90OzogJnF1b3Q7czZCaGRSa3F0MyZx dW90Oyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyZx dW90O2lhdCZxdW90OzogMTQ3MTU2NjE1NCw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7ICZuYnNwOyZxdW90O2p0aSZxdW90OzogJnF1b3Q7YldKcSZxdW90Oyw8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyZxdW90O2V2ZW50 cyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5i c3A7ICZuYnNwOyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfZXZlbnRfcmlzY19fYWNjb3Vu dC0yRGRpc2FibGVkJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smYW1wO209ZzVFOGwtSFlqTWl1NjZKZy1GZGUxY0JnMzZYN1R1dUhwOGR4Sjdz U1l5ayZhbXA7cz1iWnhfbmhhUmU3Q0NhUjFZMEVJaXB4SDhScVdDV0RvQk80X21mdm1meUVVJmFt cDtlPSI+aHR0cDovL3NjaGVtYXMub3BlbmlkLm5ldC9ldmVudC9yaXNjLy9hY2NvdW50LWRpc2Fi bGVkPC9hPiZxdW90OzoNCiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3JlYXNvbiZxdW90OzogJnF1b3Q7aGlqYWNr aW5nJnF1b3Q7LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtlbWFpbCZxdW90OzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OmJvYkBleGFtcGxlLmNvbSI+Ym9iQGV4YW1wbGUuY29tPC9hPiZxdW90Oyw8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDt9PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPn08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ TWFyaXVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBUaHUsIEp1 biAyMiwgMjAxNyBhdCAxMDowNSBBTSwgUGhpbCBIdW50PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+V2XigJl2ZSBoYWQgYSBsb25nIHN0YW5kaW5nIHRocmVhZCBv biBob3cgdG8gaGFuZGxlIHVzZSBvZiDigJxzdWLigJ0gYW5kIOKAnGlzc+KAnSBpbiBTRVQuJm5i c3A7IEnigJlkIGxpa2UgdG8gZ2l2ZSBzb21lIGV4YW1wbGVzIHRoYXQgd2UgY2FuIGNvbXBhcmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlBsZWFzZSBhZGQgeW91ciBj b21tZW50cy4gSXQgd291bGQgYmUgZ29vZCB0byByZWFjaCBzb21lIGNvbmNsdXNpb24gaW4gdGhl IG5leHQgZmV3IGRheXMgaWYgd2UgYXJlIGdvaW5nIHRvIGNoYW5nZSB0aGUgZHJhZnQgZm9yIFBy YWd1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFu a3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRocmVlIGN1cnJlbnQg ZHJhZnQgZXhhbXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+MS4gQSBTQ0lNIEV2ZW50IGxvb2tzIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPnsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01v bmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPiZxdW90Ozx1Pmp0aTwvdT4mcXVvdDs6ICZxdW90OzNkMGMzY2Y3OTc1 ODRiZDE5M2JkMGZiMWJkNGU3ZDMwJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7PHU+aWF0PC91PiZx dW90OzogMTQ1ODQ5NjAyNSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90Ozx1PmlzczwvdT4mcXVvdDs6ICZxdW90 OzxhIGhyZWY9Imh0dHBzOi8vc2VjdXJpdHkuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9zZWN1cml0eS5leGFtcGxlLmNvbTwvYT4mcXVvdDssICZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlm Ij4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ JnF1b3Q7PHU+YXVkPC91PiZxdW90OzogWzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzk4ZDUyNDYx ZmE1YmJjODc5NTkzYjc3NTQ8L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2 ZWU3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw NDUxNmIxZDA4NjQxZDc2NzZlZTc8L2E+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5dLCAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90Oyxz ZXJpZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPiZxdW90O3N1YiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUu Y29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOTwvYT4m cXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtN b25hY28mcXVvdDssc2VyaWYiPiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDtldmVudHMmcXVvdDs6IHs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4m cXVvdDt1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpwYXNzd29yZFJlc2V0JnF1b3Q7OiB7IH08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZx dW90OyxzZXJpZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01vbmFjbyZxdW90OyxzZXJpZiI+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjIuIEFuIE9QIGlz c3VlZCBCYWNrY2hhbm5lbCBMb2dvdXQgKHNpbmdsZS1zaWduLW91dCkgbG9va3MgbGlrZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01v bmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwO3s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5pc3M8L3U+JnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZl ci5leGFtcGxlLmNvbTwvYT4mcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90O3N1 YiZxdW90OzogJnF1b3Q7MjQ4Mjg5NzYxMDAxJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4mcXVvdDs8dT5hdWQ8L3U+JnF1b3Q7OiAmcXVvdDtzNkJoZFJrcXQzJnF1b3Q7LDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5pYXQ8L3U+JnF1b3Q7OiAxNDcxNTY2MTU0LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5qdGk8L3U+JnF1b3Q7OiAmcXVvdDtiV0pxJnF1 b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9u YWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5zaWQ8L3U+JnF1b3Q7OiAmcXVv dDswOGE1MDE5Yy0xN2UxLTQ5NzctOGY0Mi02NWExMjg0M2VhMDImcXVvdDssPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPiZxdW90O2V2ZW50cyZxdW90OzogezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3NjaGVtYXMub3BlbmlkLm5ldF9ldmVudF9iYWNrY2hhbm5lbC0y RGxvZ291dCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZ VHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRD X2xMSUdrJmFtcDttPWc1RThsLUhZak1pdTY2SmctRmRlMWNCZzM2WDdUdXVIcDhkeEo3c1NZeWsm YW1wO3M9UmdRd0gyM3M1d1lwMHNqTGxBU0lkTlhwcHVaa2FkR3AyLTI3UDJkWG9CUSZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L2V2ZW50L2JhY2tjaGFu bmVsLWxvZ291dDwvYT4mcXVvdDs6DQoge308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+fTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7 LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+My4gQW4gUlAgaXNzdWVkIEFwcGxpY2F0aW9uIExv Z291dCBMb29rcyBsaWtlIChkaWZmZXJlbnQgaXNzdWVyKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+ ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNv JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7PHU+aXNzPC91PiZxdW90OzogJnF1b3Q7PGEgaHJlZj0i aHR0cHM6Ly9ycC5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3JwLmV4YW1w bGUuY29tPC9hPiZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90Ozx1PmF1ZDwvdT4mcXVvdDs6 ICZxdW90O3M2QmhkUmtxdDMmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5pYXQ8L3U+ JnF1b3Q7OiAxNDcxNTY2MTU0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7PHU+anRpPC91PiZxdW90 OzogJnF1b3Q7YldKcSZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90O2V2ZW50cyZxdW90Ozog ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNv JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5uZXRfZXZl bnRfcmlzYy0yRGxvZ291dCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6 ald3bE5LZTRDX2xMSUdrJmFtcDttPWc1RThsLUhZak1pdTY2SmctRmRlMWNCZzM2WDdUdXVIcDhk eEo3c1NZeWsmYW1wO3M9QnpWTjM4eFJPc0NzMVN2WmxCblRteHhCVnEwTGhfcHM5N1A1Y1lFN3FY NCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L2V2ZW50 L3Jpc2MtbG9nb3V0PC9hPiZxdW90OzoNCiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyAmbmJz cDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PiZxdW90O3N1YiZxdW90OzogJnF1b3Q7MjQ4Mjg5NzYxMDAxJnF1b3Q7LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5pc3M8L3U+JnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJo dHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlcnZl ci5leGFtcGxlLmNvbTwvYT7igJ0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7PHU+c2lkPC91PiZxdW90OzogJnF1b3Q7MDhhNTAx OWMtMTdlMS00OTc3LThmNDItNjVhMTI4NDNlYTAyJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90 OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj59PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj59PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPn08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkkgYmVsaWV2ZSB0aGUgY29uY2VybnMgaGVyZSBhcmU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VXNlIG9mIOKAnHN1YuKAnSBh bmQg4oCcaXNz4oCdIGlzIGluY29uc2lzdGVudCBhbmQgbW92ZXMgYXJvdW5kLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNDSU0gY291bGQg cmVkZWZpbmUg4oCcc3Vi4oCdIGFzIGEgVVJJIG9yIGl0IGNvdWxkIHVzZSBpdHMgb3duIGF0dHJp YnV0ZSBpbiB0aGUgcGF5bG9hZCAoaW50cm9kdWNpbmcgbW9yZSB2YXJpYWJpbGl0eSkuJm5ic3A7 IEFzIGxvbmcgYXMg4oCcc3Vi4oCdIGlzIHZhbGlkIHRvIHVzZSBpbiBTRVQgdGhhbiBwcm9maWxp bmcgc3BlY3MgY2FuIHJlZGVmaW5lIHN1Yg0KIGZvciB0aGVpciBvd24gcHVycG9zZXMuJm5ic3A7 IElzIHRoaXMgZ29vZCBvciBiYWQ/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaG9zZSB3cml0aW5nIHBhcnNlcnMgaGF2ZSB0byBiZSBjb25jZXJuZWQg dGhhdCB3aGVuIHRoZXkgYXJlIHBhcnNpbmcgYSBTRVQgdGhleSBuZWVkIHRvIGtub3cgdGhlIHJv bGUgb2YgdGhlIHNlcnZlciBPUiB0aGV5IGhhdmUgdG8gZnVsbHkgcGFyc2UgdGhlIGVudGlyZSBv YmplY3QgdG8gZGV0ZXJtaW5lIGlmIHRoZXkgYXJlIGxvb2tpbmcNCiBhdCBzdHJ1Y3R1cmUgMiBv ciAzLiZuYnNwOyBJT1cgYSBsb3Qgb2YgaW1wbGVtZW50YXRpb25zIGhhdmUgdG8gYWx3YXlzIGNo ZWNrIGZvciBhbiBlbWJlZGRlZCDigJxpc3PigJ0gdG8gYmUgc3VyZSB0aGV5IGhhdmUgdGhlIGNv cnJlY3Qgc3ViamVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkEgY29uY2VybiBhYm91dCB0aGUgdHJhZGUtb2ZmcyBpZiBtdWx0aXBsZSBldmVudCB0 eXBlcyBhcmUgZXhwcmVzc2VkLCBzaG91bGQgdGhleSBzaGFyZSBhIGNvbW1vbiB0b3AtbGV2ZWwg YXR0cmlidXRlLiBIb3cgZG9lcyB0aGlzIGltcHJvdmUgb3IgY29tcGxpY2F0ZSBtdWx0aS10eXBl IGV2ZW50cz8mbmJzcDsgSW4gdGhlIGRyYWZ0LCBub3RlDQogdGhhdCBGaWd1cmUgMSBzaG93cyBh biBldmVudCB3aXRoIGEgbG9jYWxpemVkIGV4dGVuc2lvbiB0aGF0IGFkZHMgdmFsdWUgd2l0aG91 dCBpbXBhY3RpbmcgaW50ZXItb3AuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj7igJxzaWTigJ0gaW4gRmlndXJlIDIgb2YgdGhlIFNFVCBkb2N1bWVudCBp cyBpbiB0aGUgdG9wLWxldmVsLiBXZeKAmXZlIGJlZW4gZGlzY3Vzc2luZyB0aGF0IGFkZGl0aW9u YWwgYXR0cmlidXRlcyBzaG91bGQgYmUgaW4gdGhlIHBheWxvYWQuIEl0ZW0gMyBzaG93cyBzaWQg aW4gdGhlIHBheWxvYWQuIFdoaWNoIGlzIGNvcnJlY3Q/PG86cD48L286cD48L3NwYW4+PC9saT48 L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PVBvc3NpYmxlIE9wdGlvbnM9PT09 PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QS4mbmJz cDsgV2UgY291bGQgc2F5IHRoYXQgYWxsIFNFVHMgbXVzdCBlbWJlZCBzdWIgYW5kIGlzcyAoaWYg dGhleSB1c2UgaXNzIGZvciBpZGVudGlmeWluZyBzdWJqZWN0cykgaW4gdGhlIHBheWxvYWQuJm5i c3A7IFNlZSBleGFtcGxlIDMgYWJvdmUuJm5ic3A7IFRoaXMgd291bGQgZXhjbHVkZSBvcHRpb25z IDEgYW5kIDINCiBhbmQgYXQgbGVhc3QgbWFrZSBpdCBjb25zaXN0ZW50IHRoYXQgc3ViamVjdCBp bmZvcm1hdGlvbiBpcyBhbHdheXMgaW4gdGhlIHBheWxvYWQuICZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkIuIEEgbmV3IHRvcC1sZXZlbCBhdHRy aWJ1dGUgY291bGQgYmUgZGVmaW5lZCB3aGljaCBpcyBhIEpTT04gb2JqZWN0LiBJbnNpZGUgdGhl IEpTT04gb2JqZWN0LCBwcm9maWxpbmcgc3BlY3MgY2FuIGRlZmluZSBob3cgdGhlaXIgc3ViamVj dHMgYXJlIGFkZHJlc3NlZC4gTGV04oCZcyBjYWxsIGl0IHRhcmdldC4mbmJzcDsNCiBBIG5ldyBj b21tb24gU0VUIGZvcm1hdCBtaWdodCBsb29rIHNvbWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+eyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7 PHU+anRpPC91PiZxdW90OzogJnF1b3Q7M2QwYzNjZjc5NzU4NGJkMTkzYmQwZmIxYmQ0ZTdkMzAm cXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtN b25hY28mcXVvdDssc2VyaWYiPiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5pYXQ8L3U+JnF1b3Q7OiAxNDU4NDk2MDI1LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7 LHNlcmlmIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+JnF1b3Q7PHU+aXNzPC91PiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZWN1 cml0eS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NlY3VyaXR5LmV4YW1w bGUuY29tPC9hPiZxdW90OywgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5hdWQ8L3U+JnF1b3Q7 OiBbPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25h Y28mcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1wbGUu Y29tL0ZlZWRzLzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NDwvYT4m cXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtN b25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9qaHViLmV4YW1w bGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNzwv YT4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O01vbmFjbyZxdW90OyxzZXJpZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPl0sICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6IzA0MzNGRiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzA0MzNGRiI+JnF1b3Q7dGFyZ2V0 JnF1b3Q7Ons8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtNb25hY28mcXVvdDssc2VyaWY7Y29sb3I6IzA0MzNGRiI+Jm5ic3A7ICZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDtzdWIm cXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2 MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDk8L2E+JnF1b3Q7LDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90 OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVv dDtNb25hY28mcXVvdDssc2VyaWY7Y29sb3I6IzA0MzNGRiI+Jm5ic3A7ICZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8dT5pc3M8L3U+ JnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tPC9hPiZxdW90Ozwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25h Y28mcXVvdDssc2VyaWY7Y29sb3I6IzA0MzNGRiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPn0sPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJp ZiI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PiZxdW90O2V2ZW50cyZxdW90OzogezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90O3VybjppZXRmOnBh cmFtczpzY2ltOmV2ZW50OnBhc3N3b3JkUmVzZXQmcXVvdDs6IHsgfTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+fTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7 LHNlcmlmIj59PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFt aWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGVyZSBpcyBh biBleGFtcGxlIG1vZGlmaWVkIGxvZ291dCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYi PiZuYnNwOyAmbmJzcDt7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1 b3Q7PHU+aXNzPC91PiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb208L2E+JnF1 b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9u YWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90Ozx1PmF1ZDwv dT4mcXVvdDs6ICZxdW90O3M2QmhkUmtxdDMmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7Jm5ic3A7JnF1b3Q7PHU+aWF0PC91PiZxdW90OzogMTQ3MTU2NjE1NCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90Oyxz ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDs8dT5qdGk8L3U+JnF1b3Q7OiAm cXVvdDtiV0px4oCdLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj7igJx0YXJnZXTigJ06ezxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7 LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7c3ViJnF1b3Q7OiAmcXVvdDsyNDgyODk3 NjEwMDEmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTom cXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw OyZxdW90Ozx1PnNpZDwvdT4mcXVvdDs6ICZxdW90OzA4YTUwMTljLTE3ZTEtNDk3Ny04ZjQyLTY1 YTEyODQzZWEwMuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj59PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7ZXZlbnRzJnF1b3Q7OiB7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zY2hlbWFzLm9wZW5pZC5u ZXRfZXZlbnRfYmFja2NoYW5uZWwtMkRsb2dvdXQmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1nNUU4bC1IWWpNaXU2NkpnLUZkZTFj QmczNlg3VHV1SHA4ZHhKN3NTWXlrJmFtcDtzPVJnUXdIMjNzNXdZcDBzakxsQVNJZE5YcHB1Wmth ZEdwMi0yN1AyZFhvQlEmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NjaGVtYXMub3Bl bmlkLm5ldC9ldmVudC9iYWNrY2hhbm5lbC1sb2dvdXQ8L2E+JnF1b3Q7Og0KIHt9PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDt9PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoZSBhYm92ZSBmb3JtYXRzIGFkZHJlc3MgdGhlIGZvbGxvd2luZzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4qIENvbnNpc3RlbnQg c3RydWN0dXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiogRmxleGliaWxpdHkgZm9yIHByb2ZpbGVz IHRvIHRhcmdldCBkaWZmZXJlbnRseSBidXQgdXNpbmcgYSBjb21tb24gYXR0cmlidXRlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+KiBNdWx0aXBsZSBldmVudCB0eXBlcyBzaGFyZSBhIGNvbW1vbiB0YXJn ZXQgYW5kIG11c3QgYmUgY29tcGF0aWJsZSAobm90IHN1cmUgaWYgdGhpcyBpcyBhIHBsdXMgb3Ig bWludXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+KiBObyBjb25mbGljdCBhcm91bmQgU0VUIGlzc3Vl ciB2cyBzdWJqZWN0IGlzc3VlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiogU0VUIGlzIHN1YnN0YW50 aWFsbHkgZGlmZmVyZW50IHN1Y2ggdGhhdCBleGlzdGluZyBhY2Nlc3MgdG9rZW4gYW5kIElEIHRv a2VuIGNvZGUgd2lsbCByZWplY3QgY29uc2lzdGVudGx5IChiZWNhdXNlIHN1YiBpcyBtaXNzaW5n KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiogdGFyZ2V0IGNvdWxkIGFsc28gaGF2ZSBhbiBhdHRyaWJ1 dGUgdGhhdCBpbmRpY2F0ZXMgdGhlIHRhcmdldCDigJx0eXBl4oCdIHN1Y2ggYXMgU0NJTSByZXNv dXJjZSwgT1Agc3ViamVjdCwgSVBhZGRyZXNzLCBhbmQgc28gb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xv dWQgU2VydmljZXMgQXJjaGl0ZWN0ICZhbXA7IFN0YW5kYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlk LmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPWc1RThsLUhZak1pdTY2SmctRmRlMWNCZzM2WDdUdXVIcDhkeEo3c1NZeWsmYW1w O3M9Vk92MWItNzZqYkdPdnBFR09fTy1LOWcxaERwQnpNM3dRa1B0TEtQYVNWUSZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1l dmVudEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209ZzVFOGwtSFlqTWl1NjZKZy1GZGUx Y0JnMzZYN1R1dUhwOGR4SjdzU1l5ayZhbXA7cz1xNUZLR3RFM2lHUzRYLXk4SzZ5dGg0QW4yNGNQ WnlWWHBOTmRNUEE4cndVJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB050453C8425C80321411AE3CF5DB0CY4PR21MB0504namp_-- From nobody Thu Jun 22 12:58:22 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A424129B5B for ; Thu, 22 Jun 2017 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1BZqogIExlt for ; Thu, 22 Jun 2017 12:58:14 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6306E129492 for ; Thu, 22 Jun 2017 12:58:14 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5MJsOFn024162; Thu, 22 Jun 2017 20:58:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=Ee0P2Dg2GQcdgJr8On1CAkSPEO4IeCCFAPYPVR9zaBA=; b=idHA4CEkvKAGJ+UI0LpmEiI3vguFRh7dtL62MmFJD7pG+5bRKnMAEv/Qeg4whUoRLt1f QimexT6c6p+rx41RRy2xQq7YJjERmoHlQnJCSm5iIj3VjgktLbE+IhG+36HjuepWW0Td SkluMdbQPsFPSDIIdjtrGfgXJRaTnds5XraTG9ZlNypYBvp9DSmR4GMbJs5L5SDZSAOx rSCZNUNuZnxVp6B/fdXspsZeVzXN67zdkNlX30BWJUiipOF8g108gcuizrloAilDBlVU 9z5p04VyUd66h7/tW/V0IWDqaKVwqvYv5JKuCvPoSvc5CAc3euunsg+4AiapD1k8AQwr 3A== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2b8j100vnb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2017 20:58:08 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5MJteLY002161; Thu, 22 Jun 2017 15:58:07 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b4yrvehe2-1; Thu, 22 Jun 2017 15:58:05 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 899BF20064; Thu, 22 Jun 2017 13:58:03 -0600 (MDT) To: "Phil Hunt (IDM)" , Marius Scurtescu Cc: "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , Mike Jones , John Bradley , ID Events Mailing List References: <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3! @gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <618AD3DC-778F-4C8F-B60A-92F5BDCB14F2@oracle.com> From: Benjamin Kaduk Message-ID: Date: Thu, 22 Jun 2017 14:58:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <618AD3DC-778F-4C8F-B60A-92F5BDCB14F2@oracle.com> Content-Type: multipart/alternative; boundary="------------499588EAF6A95EF9DCEEEAE8" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706220340 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706220340 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 19:58:20 -0000 This is a multi-part message in MIME format. --------------499588EAF6A95EF9DCEEEAE8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit A very abstract concern I would have is that if you have some entity issuing SETs assuming one profile, how is it ensured that everything consuming those SETs interpret it using the same profile? I know there are a lot of things deployed out there in the greater OAuth world that use out-of-band agreements between participants, but maybe we want to move away from that sort of thing. -Ben On 06/21/2017 07:25 PM, Phil Hunt (IDM) wrote: > +1 > > Phil > > On Jun 21, 2017, at 5:16 PM, Marius Scurtescu > wrote: > >> On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones >> > wrote: >> >> The proposal that I believe has the most support is keeping >> things as they are, leaving it up to profiles and applications to >> define which claims they use and how they use them. >> >> >> >> It would be fine for some profiles to use the language below. >> >> >> I don't think this is acceptable Mike. >> >> I'll summarize again. >> >> We have two open problem to solve: >> 1. SETs could be confused for other JWTs (Id Tokens and Access Tokens >> in particular). >> 2. In some cases there is an "iss" conflict at the top level, the >> "sub" related "iss" is different from the SET "iss". This is not >> specific to any particular profile. >> >> Further, problem 1 needs a short term solution and a long term >> solution. The important solution for secevent is the short term one. >> >> Out of the above only the long term solution for problem 1 has some >> promising resolution (using typ or cty). >> >> So, keeping things as they are nothing relevant to secevent is solved >> basically. >> >> Again, if your main concern is compatibility for the logout spec >> (which is understandable) then let's talk about that and see if we >> can find a solution for the two problems above with that constraint. >> Unfortunately I cannot see such a solution. >> >> >> >> >> >> >> >> – Mike >> >> *From: *Phil Hunt >> *Sent: *Wednesday, June 21, 2017 6:39 PM >> *To: *Richard Backman, Annabelle >> *Cc: *Marius Scurtescu ; John >> Bradley ; Henk Birkholz >> ; Justin Richer >> ; Yaron Sheffer >> ; Mike Jones >> ; ID Events Mailing List >> >> >> >> *Subject: *Re: [Id-event] solution for Id/Access Token confusion >> and distinct SET issuer >> >> >> >> So I understand what is being proposed is: >> >> If the event type uses “sub” to identify its subject, and the >> issuer of the subject is identical to the issuer for the event, >> then “sub” may be used at the top level. Otherwise, the subject >> of an event (e.g. “sub”) and any other claims required to >> uniquely identify the subject MUST be contained in the event payload. >> >> For example, an ip address of 1.2.3.4 might be represented in a >> “ipaddress” claim defined in the event payload. “ipaddress”:”1.2.3.4" >> A SCIM resource URI of >> https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 >> >> might be identified in the event payload as: >> “sub”:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 >> ” >> >> A Connect Logout event from an OP uses the top level sub claim >> and depends on “iss” being the same for the event issuer AND the >> subject. This means that no party may issue logout events on >> behalf of the OP. >> >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >>> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle >>> > wrote: >>> >>> Fair point. If we do not intend to support multiple profiles >>> within a single SET, then I’m less concerned about leaving sub >>> semantics up to the profiles. >>> >>> -- >>> Annabelle Richard Backman >>> Identity Services >>> >>> >>> *From: *Marius Scurtescu >> > >>> *Date: *Wednesday, June 21, 2017 at 2:58 PM >>> *To: *"Richard Backman, Annabelle" >> > >>> *Cc: *"Phil Hunt (IDM)" >> >, John Bradley >> >, Henk Birkholz >>> >> >, Justin Richer >>> >, Yaron Sheffer >>> >, Michael >>> Jones >> >, ID Events Mailing List >>> > >>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion >>> and distinct SET issuer >>> >>> Example for multiple events within same profile: IdP account is >>> disabled (because of hijacking), this can lead to two events: >>> 1. "account-disabled" >>> 2. "sessions-revoked" >>> >>> Marius >>> >>> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle >>> > wrote: >>>> The spec says that the events claim SHOULD NOT be used to >>>> express multiple logical events. If it’s also not used to >>>> express events from different profiles that correspond to the >>>> same logical event (e.g. an OIDC backchannel logout event >>>> alongside a hypothetical RISC logout event), then I’m not sure >>>> what use case that leaves for multiple events in one SET. >>>> >>>> -- >>>> Annabelle Richard Backman >>>> Identity Services >>>> >>>> >>>> *From: *Id-event >>> > on behalf of "Phil Hunt >>>> (IDM)" > >>>> *Date: *Wednesday, June 21, 2017 at 2:12 PM >>>> *To: *John Bradley > >>>> *Cc: *"Richard Backman, Annabelle" >>> >, Henk Birkholz >>>> >>> >, Justin Richer >>>> >, Marius Scurtescu >>>> >, Yaron >>>> Sheffer >, >>>> Michael Jones >>> >, ID Events Mailing List >>>> > >>>> >>>> *Subject: *Re: [Id-event] solution for Id/Access Token >>>> confusion and distinct SET issuer >>>> >>>> Separate or combined may be evolving. Mike wants to keep the >>>> current backchannel logout very narrowly scoped. He suggested >>>> risc define its own duplicate definitions and meanings. >>>> >>>> That leads me to believe we will have multi-type events in >>>> practice. >>>> >>>> Session cancellation can occur for many reasons. One of the >>>> differentiators we had tried to make was an assumption that >>>> user initiated events would be part of connect. Risk would >>>> cover variations that drive off of risk calculations like >>>> password reset. >>>> >>>> There are also signout events at rp's to let the OP know. These >>>> are not commands but notification that a resource session is >>>> cancelled. IOW single sign out not expected. >>>> >>>> Phil >>>> >>>> >>>> On Jun 21, 2017, at 1:58 PM, John Bradley >>> > wrote: >>>>> I thought we decided that we are only allowing set messages >>>>> form the same family that agree on top level claims. >>>>> >>>>> Otherwise there can be no top level claims and we are really >>>>> defining a alternative format to JWT in some ways. >>>>> >>>>> John B. >>>>> >>>>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle >>>>>> > wrote: >>>>>> >>>>>> I agree with John that the JWT type confusion problem and the >>>>>> SET sub problem can and should be discussed separately. The >>>>>> secevents WG is probably not the right setting to discuss the >>>>>> former. >>>>>> >>>>>> My concern with the sub claim is that two profiles may >>>>>> dictate conflicting semantics (e.g. Profile A says it’s a >>>>>> phone number, Profile B says it’s an email address). If these >>>>>> profiles don’t provide an alternate way to declare subject of >>>>>> their events, then they cannot be present within the same >>>>>> token. This incompatibility trap seems like something that >>>>>> could be easily missed by groups profiling SET. >>>>>> >>>>>> -- >>>>>> Annabelle Richard Backman >>>>>> Identity Services >>>>>> >>>>>> >>>>>> *From: *John Bradley >>>>> > >>>>>> *Date: *Wednesday, June 21, 2017 at 1:39 PM >>>>>> *To: *Yaron Sheffer >>>>> > >>>>>> *Cc: *Justin Richer >>>>> >, Marius Scurtescu >>>>>> >, >>>>>> Annabelle Richard >>>>> >, Phil Hunt >>>>>> >, Michael >>>>>> Jones >>>>> >, ID Events Mailing List >>>>>> >, Henk Birkholz >>>>>> >>>>> > >>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token >>>>>> confusion and distinct SET issuer >>>>>> >>>>>> In the envelope typ is a media/mime type. Registering >>>>>> application/idt+jwt if we register jwt as a structured name >>>>>> sufix. >>>>>> >>>>>> Using the cty is also possible. I need to think about what >>>>>> is better but we can agree on a convention. >>>>>> >>>>>> Not everything is going to be a set token like not every JWS >>>>>> is a JWT. >>>>>> >>>>>> If we are going to define processing rules to stop collisions >>>>>> and confusion around JWT for different purposes, we should >>>>>> just start using the typ parameter based on the existing spec. >>>>>> >>>>>> In general content sniffing if there is more than one option >>>>>> eventually gets you into trouble. >>>>>> >>>>>> I am not convinced that forcing there to be no sub at the top >>>>>> level is a good idea. >>>>>> >>>>>> It is not the way we should differentiate between SET and >>>>>> id_tokens. >>>>>> >>>>>> If sub is not allowed at the top level people will do non SET >>>>>> JWT for things where the subject is scoped to the iss of the >>>>>> token. >>>>>> >>>>>> I think defining sub to be part of the event for cases where >>>>>> the sub is scoped differently from the issuer of the token is >>>>>> fine, but should not be required for all event types. >>>>>> >>>>>> I think we should solve the confusion issue separately from >>>>>> the sub issue. >>>>>> >>>>>> Sorry I am at CIS so trying to catch up on lists. >>>>>> >>>>>> John B. >>>>>> >>>>>>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer >>>>>>> > wrote: >>>>>>> >>>>>>> So to summarize what I'm seeing on this thread: >>>>>>> Everybody agrees with Marius's short-term solution, specific >>>>>>> rules for "sub" and "iss" that can be defined in the SET spec. >>>>>>> Almost everybody agrees on a long-term "usage" claim ("type" >>>>>>> is taken) that should be defined elsewhere, e.g. in the JWT BCP. >>>>>>> Did I miss anything? >>>>>>> By the way, if we do add a "usage" claim, we need to also >>>>>>> use it in the SET document before it is published. >>>>>>> Thanks, >>>>>>> Yaron >>>>>>> >>>>>>> On 15/06/17 22:08, Justin Richer wrote: >>>>>>>> +1 to this as well. >>>>>>>> >>>>>>>> — Justin >>>>>>>> >>>>>>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> +1 to what Annabelle said. >>>>>>>>> >>>>>>>>> Also, Mike you are missing the other requirement, for RPs >>>>>>>>> to send events to an IdP. The iss+sub pair at the top >>>>>>>>> level is broken in this case. >>>>>>>>> >>>>>>>>> Marius >>>>>>>>> >>>>>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) >>>>>>>>> > wrote: >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> Phil >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle >>>>>>>>>> > wrote: >>>>>>>>>>> Mike, >>>>>>>>>>> >>>>>>>>>>> Your explanation for why this is a non-problem is >>>>>>>>>>> dependent upon side effects of elements of OpenID >>>>>>>>>>> Connect that were not designed to solve this issue. As a >>>>>>>>>>> result, I see several issues with it: >>>>>>>>>>> >>>>>>>>>>> 1. The caller of the Token Endpoint is the only >>>>>>>>>>> party that can be certain that a nonce-less ID Token is >>>>>>>>>>> really an ID Token. Any party that the caller passes the >>>>>>>>>>> ID Token off to has no way to verify its provenance. >>>>>>>>>>> >>>>>>>>>>> 2. Any future ID Token distribution method needs >>>>>>>>>>> to solve this problem again. >>>>>>>>>>> >>>>>>>>>>> 3. No other profile of JWT can ever use the "nonce” >>>>>>>>>>> claim. >>>>>>>>>>> >>>>>>>>>>> 4. This is only a solution for ID Tokens. Every >>>>>>>>>>> other JWT profile that cares about disambiguation has to >>>>>>>>>>> invent its own solution to the problem. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We know from experience that naming collisions and >>>>>>>>>>> replay attacks are both things that happen. What’s being >>>>>>>>>>> proposed is a simple, defensive measure against these >>>>>>>>>>> risks. You brought up JWT libraries: a general solution >>>>>>>>>>> actually makes it easier to use common libraries for JWT >>>>>>>>>>> parsing. A “usage-aware” JWT library could handle >>>>>>>>>>> disambiguation for any JWT profile, whereas with the >>>>>>>>>>> status quo each profile would require unique logic. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *From: *Id-event >>>>>>>>>> > on behalf of Mike >>>>>>>>>>> Jones >>>>>>>>>> > >>>>>>>>>>> *Date: *Wednesday, June 14, 2017 at 1:16 PM >>>>>>>>>>> *To: *Marius Scurtescu >>>>>>>>>> > >>>>>>>>>>> *Cc: *"Richard Backman, Annabelle" >>>>>>>>>> >, ID Events Mailing List >>>>>>>>>>> >, Henk >>>>>>>>>>> Birkholz >>>>>>>>>> > >>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token >>>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>>> >>>>>>>>>>> You’ve heard of “premature optimization”. I’d >>>>>>>>>>> characterize the proposals in this thread as “premature >>>>>>>>>>> pessimation” – making things that can and should be >>>>>>>>>>> simple complex, without data showing there’s any need to >>>>>>>>>>> do so. >>>>>>>>>>> >>>>>>>>>>> Mandatory solutions are being proposed in this thread to >>>>>>>>>>> problems that there’s no evidence that we actually even >>>>>>>>>>> have. It’s already been established that it’s >>>>>>>>>>> impossible for a SET to be confused for an ID Token – >>>>>>>>>>> see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html >>>>>>>>>>> . >>>>>>>>>>> If people have data showing that this is possible with >>>>>>>>>>> specific kinds of Access Tokens or other real JWT >>>>>>>>>>> deployments, please provide specifics, so that we can >>>>>>>>>>> use that data to inform appropriate engineering choices >>>>>>>>>>> on our part. >>>>>>>>>>> >>>>>>>>>>> The proposed “solutions”, such as prohibiting the use of >>>>>>>>>>> “sub” in the normal way, or requiring a type claim, >>>>>>>>>>> would make previously simple things unnecessarily >>>>>>>>>>> complex. Yes, then the result is then different than a >>>>>>>>>>> normal JWT but a consequence of this is that custom >>>>>>>>>>> parsing code would have to be used, rather than a >>>>>>>>>>> standard JWT parser. The more unwieldy we make it to >>>>>>>>>>> use SETs, the more likely developers are to just create >>>>>>>>>>> their own data structures. Keeping it simple is the key >>>>>>>>>>> to adoption. Standards are only useful if they are >>>>>>>>>>> actually used. >>>>>>>>>>> >>>>>>>>>>> -- Mike >>>>>>>>>>> >>>>>>>>>>> *From:* Id-event [mailto:id-event-bounces@ietf.org >>>>>>>>>>> ] *On Behalf >>>>>>>>>>> Of *Richard Backman, Annabelle >>>>>>>>>>> *Sent:* Tuesday, June 13, 2017 5:33 PM >>>>>>>>>>> *To:* Marius Scurtescu >>>>>>>>>> >; Henk Birkholz >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> *Cc:* ID Events Mailing List >>>>>>>>>> > >>>>>>>>>>> *Subject:* Re: [Id-event] solution for Id/Access Token >>>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>>> >>>>>>>>>>> Echoing Marius’s question: can you explain what you mean >>>>>>>>>>> by “intend”? >>>>>>>>>>> >>>>>>>>>>> To your first question, I think a better analogy would >>>>>>>>>>> be the X.509 Key Usage extension: a multi-valued >>>>>>>>>>> property that declares the intended purpose of the JWT, >>>>>>>>>>> and that a recipient may refer to when determining >>>>>>>>>>> whether to accept a JWT being presented to it in some >>>>>>>>>>> context. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *From: *Id-event >>>>>>>>>> > on behalf of Marius >>>>>>>>>>> Scurtescu >>>>>>>>>> > >>>>>>>>>>> *Date: *Tuesday, June 13, 2017 at 11:05 AM >>>>>>>>>>> *To: *Henk Birkholz >>>>>>>>>> > >>>>>>>>>>> *Cc: *ID Events Mailing List >>>>>>>>>> > >>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token >>>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>>> And a 2nd question. >>>>>>>>>>>> >>>>>>>>>>>> What semantics would "usage" provide that that are not >>>>>>>>>>>> covered via "intend", "audience", and "scope"? >>>>>>>>>>> >>>>>>>>>>> "aud" (audience) specifies the target client, but not >>>>>>>>>>> the intended usage (access token to authorize resource >>>>>>>>>>> access or SET to communicate a security event?) >>>>>>>>>>> >>>>>>>>>>> "scope" is not used by SET. >>>>>>>>>>> >>>>>>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Henk >>>>>>>>>>>> >>>>>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>>> >>>>>>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>>>>> >>>>>>>>>>>>> ·We can’t guarantee that every type of JWT will have a >>>>>>>>>>>>> mutually exclusive set of valid claims and/or header >>>>>>>>>>>>> parameters, and enforcing this requires a “fail on an >>>>>>>>>>>>> unrecognized claim” approach to ensure that JWTs from >>>>>>>>>>>>> some future spec can’t be mistaken for JWTs from a >>>>>>>>>>>>> current spec. >>>>>>>>>>>>> >>>>>>>>>>>>> ·It is unrealistic to expect implementers to adhere to >>>>>>>>>>>>> the “different keys for different kinds of JWTs” rule. >>>>>>>>>>>>> Whether mandated by the spec or not, implementers will >>>>>>>>>>>>> ignore this because managing one key is easier than >>>>>>>>>>>>> managing N different keys. >>>>>>>>>>>>> >>>>>>>>>>>>> ·Ditto for “aud” and “iss” claims. >>>>>>>>>>>>> >>>>>>>>>>>>> +1 for a “type” or “usage” claim/header parameter. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>> >>>>>>>>>>>>> Identity Services >>>>>>>>>>>>> >>>>>>>>>>>>> *From: *Id-event >>>>>>>>>>>> > on behalf of Dick >>>>>>>>>>>>> Hardt > >>>>>>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>>>>>> *To: *Marius Scurtescu >>>>>>>>>>>> > >>>>>>>>>>>>> *Cc: *Adam Dawes >>>>>>>>>>>> >, "matake, nov" >>>>>>>>>>>>> >, ID Events >>>>>>>>>>>>> Mailing List >>>>>>>>>>>> >, "Phil Hunt (IDM)" >>>>>>>>>>>>> > >>>>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token >>>>>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>>>>> >>>>>>>>>>>>> Agreed. Note that there is still lots of discussion on >>>>>>>>>>>>> what should be in 3.9. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>>>>> >>>>>>>>>>>>> The issue is described by "2.7. Cross-JWT >>>>>>>>>>>>> Confusion" and the >>>>>>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive >>>>>>>>>>>>> Validation Rules for >>>>>>>>>>>>> Different Kinds of JWTs", specifically "Use >>>>>>>>>>>>> different sets of >>>>>>>>>>>>> required claims...", "Use different keys for >>>>>>>>>>>>> different kinds of >>>>>>>>>>>>> JWTs." and "Use different issuers for different >>>>>>>>>>>>> kinds of JWTs.". >>>>>>>>>>>>> >>>>>>>>>>>>> I still think that a "type" claim would bring a >>>>>>>>>>>>> lot of clarity and >>>>>>>>>>>>> safety. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Marius >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>>>>>> http://self-issued.info/?p=1690 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I was initially a fan of keeping SETS to >>>>>>>>>>>>> be very similar to >>>>>>>>>>>>> id tokens but I now think this is a better >>>>>>>>>>>>> plan. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 especially for "type" >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 >>>>>>>>>>>>> >>>>>>>>>>>>> Phil >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > On Jun 8, 2017, at 6:28 PM, >>>>>>>>>>>>> Marius Scurtescu >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > There were a couple of >>>>>>>>>>>>> proposals on how to >>>>>>>>>>>>> distinguish SETs from Id Tokens >>>>>>>>>>>>> and Access Tokens in >>>>>>>>>>>>> such a way that naive >>>>>>>>>>>>> implementations will not >>>>>>>>>>>>> confuse one for the other and open >>>>>>>>>>>>> up security >>>>>>>>>>>>> vulnerabilities. >>>>>>>>>>>>> > >>>>>>>>>>>>> > There is also another important >>>>>>>>>>>>> requirement: the >>>>>>>>>>>>> SET issuer in some cases must be >>>>>>>>>>>>> different from the >>>>>>>>>>>>> "sub" issuer. This is the case of >>>>>>>>>>>>> an RP sending SETs >>>>>>>>>>>>> to an IdP. >>>>>>>>>>>>> > >>>>>>>>>>>>> > With these requirements in mind >>>>>>>>>>>>> I propose the >>>>>>>>>>>>> following: >>>>>>>>>>>>> > - both "sub" and "iss" to be >>>>>>>>>>>>> defined at the event >>>>>>>>>>>>> level >>>>>>>>>>>>> > - "iss" at event level and at >>>>>>>>>>>>> top SET level can >>>>>>>>>>>>> be different >>>>>>>>>>>>> > - "iss" and "sub" at event >>>>>>>>>>>>> level can be different >>>>>>>>>>>>> across events in the same SET >>>>>>>>>>>>> > - "sub" should NOT be present >>>>>>>>>>>>> at the top SET >>>>>>>>>>>>> level (this solves the >>>>>>>>>>>>> disambiguation), please note >>>>>>>>>>>>> "should" and not "must" >>>>>>>>>>>>> > >>>>>>>>>>>>> > This solution also allows >>>>>>>>>>>>> different profiles that >>>>>>>>>>>>> define event types to define >>>>>>>>>>>>> additional claims >>>>>>>>>>>>> related to sub (like email or >>>>>>>>>>>>> phone_number) and >>>>>>>>>>>>> since all these claims will be at >>>>>>>>>>>>> the event level >>>>>>>>>>>>> there will be no collisions or >>>>>>>>>>>>> ambiguity. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Another proposal (which I >>>>>>>>>>>>> supported) was to >>>>>>>>>>>>> define a composite "aud" claim. >>>>>>>>>>>>> This is not solving >>>>>>>>>>>>> the requirement for a distinct >>>>>>>>>>>>> SET issuer. Also, >>>>>>>>>>>>> having the same claim name having >>>>>>>>>>>>> different syntax >>>>>>>>>>>>> in different token types could >>>>>>>>>>>>> lead to confusion. >>>>>>>>>>>>> > >>>>>>>>>>>>> > And yet another proposal was to >>>>>>>>>>>>> introduce a new >>>>>>>>>>>>> claim for JWTs that defines a >>>>>>>>>>>>> "type". This is not >>>>>>>>>>>>> practical in the short term, and >>>>>>>>>>>>> it also is not >>>>>>>>>>>>> solving the distinct issuer >>>>>>>>>>>>> requirement, but I think >>>>>>>>>>>>> this is something the JWT group >>>>>>>>>>>>> should seriously >>>>>>>>>>>>> consider. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thoughts? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Marius >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> > Id-event mailing list >>>>>>>>>>>>> >>>>>>>>>>>>> > Id-event@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Adam Dawes | Sr. Product Manager >>>>>>>>>>>>> |adawes@google.com >>>>>>>>>>>>> >>>>>>>>>>>> > |+1 650-214-2410 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Subscribe to the HARDTWARE >>>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>>> mail list to >>>>>>>>>>>>> learn about projects I am working on! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Subscribe to the HARDTWARE >>>>>>>>>>>> > >>>>>>>>>>>>> mail list to learn about projects I am working on! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e= >>>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>> >> >> > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------499588EAF6A95EF9DCEEEAE8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit A very abstract concern I would have is that if you have some entity issuing SETs assuming one profile, how is it ensured that everything consuming those SETs interpret it using the same profile?  I know there are a lot of things deployed out there in the greater OAuth world that use out-of-band agreements between participants, but maybe we want to move away from that sort of thing.

-Ben

On 06/21/2017 07:25 PM, Phil Hunt (IDM) wrote:
+1

Phil

On Jun 21, 2017, at 5:16 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The proposal that I believe has the most support is keeping things as they are, leaving it up to profiles and applications to define which claims they use and how they use them.

 

It would be fine for some profiles to use the language below.


I don't think this is acceptable Mike.

I'll summarize again.

We have two open problem to solve:
1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in particular).
2. In some cases there is an "iss" conflict at the top level, the "sub" related "iss" is different from the SET "iss". This is not specific to any particular profile.

Further, problem 1 needs a short term solution and a long term solution. The important solution for secevent is the short term one.

Out of the above only the long term solution for problem 1 has some promising resolution (using typ or cty).

So, keeping things as they are nothing relevant to secevent is solved basically.

Again, if your main concern is compatibility for the logout spec (which is understandable) then let's talk about that and see if we can find a solution for the two problems above with that constraint. Unfortunately I cannot see such a solution.



 

 

– Mike

From: Phil Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List


Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

So I understand what is being proposed is:

If the event type uses “sub” to identify its subject, and the issuer of the subject is identical to the issuer for the event, then “sub” may be used at the top level. Otherwise, the subject of an event (e.g. “sub”) and any other claims required to uniquely identify the subject MUST be contained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a “ipaddress” claim defined in the event payload. “ipaddress”:”1.2.3.4"

A Connect Logout event from an OP uses the top level sub claim and depends on “iss” being the same for the event issuer AND the subject. This means that no party may issue logout events on behalf of the OP.


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Fair point. If we do not intend to support multiple profiles within a single SET, then I’m less concerned about leaving sub semantics up to the profiles.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Marius Scurtescu <mscurtescu@google.com>
Date: Wednesday, June 21, 2017 at 2:58 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
Example for multiple events within same profile: IdP account is disabled (because of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the events claim SHOULD NOT be used to express multiple logical events. If it’s also not used to express events from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then I’m not sure what use case that leaves for multiple events in one SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Date: Wednesday, June 21, 2017 at 2:12 PM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>

Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
Separate or combined may be evolving. Mike wants to keep the current backchannel logout very narrowly scoped. He suggested risc define its own duplicate definitions and meanings. 
 
That leads me to believe we will have multi-type events in practice.
 
Session cancellation can occur for many reasons. One of the differentiators we had tried to make was an assumption that user initiated events would be part of connect. Risk would cover variations that drive off of risk calculations like password reset. 
 
There are also signout events at rp's to let the OP know. These are not commands but notification that a resource session is cancelled. IOW single sign out not expected. 

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I thought we decided that we are only allowing set messages form the same family that agree on top level claims.
 
Otherwise there can be no top level claims and we are really defining a alternative format to JWT in some ways.
 
John B.
 
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
 
I agree with John that the JWT type confusion problem and the SET sub problem can and should be discussed separately. The secevents WG is probably not the right setting to discuss the former.
 
My concern with the sub claim is that two profiles may dictate conflicting semantics (e.g. Profile A says it’s a phone number, Profile B says it’s an email address). If these profiles don’t provide an alternate way to declare subject of their events, then they cannot be present within the same token. This incompatibility trap seems like something that could be easily missed by groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
In the envelope typ is a media/mime type.  Registering application/idt+jwt if we register jwt as a structured name sufix.  
 
Using the cty is also possible.   I need to think about what is better but we can agree on a convention.
 
Not everything is going to be a set token like not every JWS is a JWT.
 
If we are going to define processing rules to stop collisions and confusion around JWT for different purposes, we should just start using the typ parameter based on the existing spec.
 
In general content sniffing if there is more than one option eventually gets you into trouble.
 
I am not convinced that forcing there to be no sub at the top level is a good idea.  
 
It is not the way we should differentiate between SET and id_tokens.
 
If sub is not allowed at the top level people will do non SET JWT for things where the subject is scoped to the iss of the token.
 
I think defining sub to be part of the event for cases where the sub is scoped differently from the issuer of the token is fine, but should not be required for all event types.
 
I think we should solve the confusion issue separately from the sub issue.
 
Sorry I am at CIS so trying to catch up on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.
Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well. 
 
 — Justin
 
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what Annabelle said. 
 
Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
 
Phil

 

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
 
Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.       Any future ID Token distribution method needs to solve this problem again.

3.      No other profile of JWT can ever use the "nonce” claim.

4.      This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

 
We know from experience that naming collisions and replay attacks are both things that happen. What’s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A “usage-aware” JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
You’ve heard of “premature optimization”.  I’d characterize the proposals in this thread as “premature pessimation” – making things that can and should be simple complex, without data showing there’s any need to do so.
 
Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have.  It’s already been established that it’s impossible for a SET to be confused for an ID Token – see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
 
The proposed “solutions”, such as prohibiting the use of “sub” in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser.  The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key to adoption.  Standards are only useful if they are actually used.
 
                                                -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
Echoing Marius’s question: can you explain what you mean by “intend”?
 
To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?
 
"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)
 
"scope" is not used by SET.
 
I don't know what do you mean by "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

·We can’t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a “fail on an unrecognized claim” approach to ensure that JWTs from some future spec can’t be mistaken for JWTs from a current spec.

·It is unrealistic to expect implementers to adhere to the “different keys for different kinds of JWTs” rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

·Ditto for “aud” and “iss” claims.

+1 for a “type” or “usage” claim/header parameter.

-- 

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, very good timing :-)

    The issue is described by "2.7. Cross-JWT Confusion" and the
    mitigation is in "3.9. Use Mutually Exclusive Validation Rules for
    Different Kinds of JWTs", specifically "Use different sets of
    required claims...", "Use different keys for different kinds of
    JWTs." and "Use different issuers for different kinds of JWTs.".

    I still think that a "type" claim would bring a lot of clarity and
    safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just published an BCP ID for JWT
        http://self-issued.info/?p=1690

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I was initially a fan of keeping SETS to be very similar to
            id tokens but I now think this is a better plan.

            On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "type"

                2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
                <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

                    +1

                    Phil


                     > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <mscurtescu@google.com
                    <mailto:mscurtescu@google.com>> wrote:
                     >
                     > There were a couple of proposals on how to
                    distinguish SETs from Id Tokens and Access Tokens in
                    such a way that naive implementations will not
                    confuse one for the other and open up security
                    vulnerabilities.
                     >
                     > There is also another important requirement: the
                    SET issuer in some cases must be different from the
                    "sub" issuer. This is the case of an RP sending SETs
                    to an IdP.
                     >
                     > With these requirements in mind I propose the
                    following:
                     > - both "sub" and "iss" to be defined at the event
                    level
                     > - "iss" at event level and at top SET level can
                    be different
                     > - "iss" and "sub" at event level can be different
                    across events in the same SET
                     > - "sub" should NOT be present at the top SET
                    level (this solves the disambiguation), please note
                    "should" and not "must"
                     >
                     > This solution also allows different profiles that
                    define event types to define additional claims
                    related to sub (like email or phone_number) and
                    since all these claims will be at the event level
                    there will be no collisions or ambiguity.
                     >
                     > Another proposal (which I supported) was to
                    define a composite "aud" claim. This is not solving
                    the requirement for a distinct  SET issuer. Also,
                    having the same claim name having different syntax
                    in different token types could lead to confusion.
                     >
                     > And yet another proposal was to introduce a new
                    claim for JWTs that defines a "type". This is not
                    practical in the short term, and it also is not
                    solving the distinct issuer requirement, but I think
                    this is something the JWT group should seriously
                    consider.
                     >
                     > Thoughts?
                     >
                     > Marius

                     > _______________________________________________
                     > Id-event mailing list

                     > Id-event@ietf.org <mailto:Id-event@ietf.org>
                     >
                    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=

                    _______________________________________________
                    Id-event mailing list
                    Id-event@ietf.org <mailto:Id-event@ietf.org>
                    https://www.ietf.org/mailman/listinfo/id-event

                _______________________________________________
                Id-event mailing list
                Id-event@ietf.org <mailto:Id-event@ietf.org>
                https://www.ietf.org/mailman/listinfo/id-event

            -- 
            Adam Dawes | Sr. Product Manager |adawes@google.com
            <mailto:adawes@google.com> |+1 650-214-2410
            <tel:(650)%20214-2410>

            _______________________________________________
            Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
            https://www.ietf.org/mailman/listinfo/id-event

        -- 
        Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working on!



-- 

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 




_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 




_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

--------------499588EAF6A95EF9DCEEEAE8-- From nobody Thu Jun 22 13:02:22 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78945129478 for ; Thu, 22 Jun 2017 13:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llX6wj-fqDyl for ; Thu, 22 Jun 2017 13:02:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E69127444 for ; Thu, 22 Jun 2017 13:02:16 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5MK2EJR017836 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 20:02:14 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5MK2DKs016903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jun 2017 20:02:13 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5MK2BID001942; Thu, 22 Jun 2017 20:02:12 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jun 2017 13:02:10 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-3EB99A89-1C6F-4EA2-8450-C021040D4E93 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 22 Jun 2017 13:02:07 -0700 Cc: Marius Scurtescu , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <37A49764-1ED7-4355-8FEA-1B8CB8D34724@oracle.com> References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> To: Mike Jones X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 20:02:21 -0000 --Apple-Mail-3EB99A89-1C6F-4EA2-8450-C021040D4E93 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We agree on the objectives but we disagree on what defines simple and intero= perable.=20 I foresee a lot of incompatibilities emerging based on the current draft.=20= We have a lot of "if this" exception logic trying to permit the OpenId specs= to remain unchanged at the cost of clarity for general use.=20 In the general, the subject of events are often expressed as composites (mor= e than one attribute). The connect use of sub and iss is but one example.=20= Re-using iss as the part of the subject causes confusion outside of Connect b= ecause it appears inconsistent to those that cannot take the shortcut of dua= l meaning use of iss. Within Connect causes inconsistency when RPs issue eve= nts because they need two iss values. One for sub and one for the set issuer= .=20 IMO the spec needs a lot of clarifying language or a more universal and cons= istent way to express simple and composite subjects.=20 I am looking at a couple more options this aft for the groups consideration.= =20 Phil > On Jun 22, 2017, at 12:45 PM, Mike Jones wro= te: >=20 > It seems to me that most of the discussions motiving the proposals being m= ade have been implicitly assuming that SETs are about digital identities. I= n many of our use cases, they will be, which is great. I fully support stru= cting events for identity profiles to meet the needs of those use cases, inc= luding often having a distinct SET issuer from the digital identity =E2=80=9C= iss=E2=80=9D value and having it and the digital identity =E2=80=9Csub=E2=80= =9D be in the event structure, when needed. > =20 > But just like JWTs are great for digital identities (consider ID Tokens) b= ut are used in completely unrelated ways as well (such as Caller-ID standard= s), SETs should be great for digital identities (consider RISC and SCIM prof= iles) but also be great for unrelated use cases. > =20 > In some use cases there will be only one =E2=80=9Ciss=E2=80=9D and the =E2= =80=9Csub=E2=80=9D may be very different from those we use for identities. W= e would be doing everyone a disservice to many use cases if we tried to forc= e that =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D be present at the eve= nt level, when those profiles don=E2=80=99t need it there. > =20 > We shouldn=E2=80=99t make every SET use more complicated syntax that only m= ore advanced use cases actually need. Therefore, we should leave the =E2=80= =9Csub=E2=80=9D and other claims descriptions as they are. Right now it=E2=80= =99s general purpose and simple. Let=E2=80=99s not needlessly break that. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Thursday, June 22, 2017 12:58 PM > To: Marius Scurtescu > Cc: ID Events Mailing List > Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC T= oken Draft > =20 > Agreed to all your comments. And yes, =E2=80=9Ctarget=E2=80=9D is not the= best name. Just can=E2=80=99t think of one at the moment. > =20 > Thanks for the additional example. =20 > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Jun 22, 2017, at 10:53 AM, Marius Scurtescu wro= te: > =20 > Thanks Phil, concrete examples are very useful. > =20 > The top level "target" attribute is interesting, it reduces redundancy acr= oss events (when multiple events are present in one SET) but it is enforcing= a single profile per SET. As you mention, not sure if this is good or bad.= > =20 > Also, not sure about the name of the attribute, "target", but I cannot com= e up with a better name. "target" sounds like "audience". We need something a= long with "events subject". Maybe simply nest the "iss", "sub" and other rig= ht under "events"? > =20 > Here is one more example of a SET not using "sub". SETs between an email p= rovider and an implicit RP would use the OIDC defined "email" attribute (or "= phone_number"): > { > "iss": "https://rp.example.com", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "events": { > "http://schemas.openid.net/event/risc//account-disabled": { > "reason": "hijacking", > "email": "bob@example.com", > } > } > } > =20 > =20 > =20 > =20 >=20 > Marius > =20 > On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt wrote: > We=E2=80=99ve had a long standing thread on how to handle use of =E2=80=9C= sub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET. I=E2=80=99d like to give som= e examples that we can compare. > =20 > Please add your comments. It would be good to reach some conclusion in the= next few days if we are going to change the draft for Prague. > =20 > Thanks! > =20 > Three current draft examples: > =20 > 1. A SCIM Event looks like: > {=20 > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://security.example.com", =20 > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], =20 > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > "events": { > "urn:ietf:params:scim:event:passwordReset": { } > } > } > =20 > 2. An OP issued Backchannel Logout (single-sign-out) looks like: > { > "iss": "https://server.example.com", > "sub": "248289761001", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02", > "events": { > "http://schemas.openid.net/event/backchannel-logout": {} > } > } > =20 > 3. An RP issued Application Logout Looks like (different issuer): > { > "iss": "https://rp.example.com", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq", > "events": { > "http://schemas.openid.net/event/risc-logout": { > "sub": "248289761001", > "iss": "https://server.example.com=E2=80=9D, > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" > } > } > } > =20 > I believe the concerns here are: > =20 > Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent and= moves around. =20 > SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its own= attribute in the payload (introducing more variability). As long as =E2=80= =9Csub=E2=80=9D is valid to use in SET than profiling specs can redefine sub= for their own purposes. Is this good or bad? > Those writing parsers have to be concerned that when they are parsing a SE= T they need to know the role of the server OR they have to fully parse the e= ntire object to determine if they are looking at structure 2 or 3. IOW a lo= t of implementations have to always check for an embedded =E2=80=9Ciss=E2=80= =9D to be sure they have the correct subject. > A concern about the trade-offs if multiple event types are expressed, shou= ld they share a common top-level attribute. How does this improve or complic= ate multi-type events? In the draft, note that Figure 1 shows an event with= a localized extension that adds value without impacting inter-op. > =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top-level.= We=E2=80=99ve been discussing that additional attributes should be in the p= ayload. Item 3 shows sid in the payload. Which is correct? > =20 > =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D > =20 > A. We could say that all SETs must embed sub and iss (if they use iss for= identifying subjects) in the payload. See example 3 above. This would exc= lude options 1 and 2 and at least make it consistent that subject informatio= n is always in the payload. =20 > =20 > B. A new top-level attribute could be defined which is a JSON object. Insi= de the JSON object, profiling specs can define how their subjects are addres= sed. Let=E2=80=99s call it target. A new common SET format might look somet= hing like: > =20 > {=20 > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", > "iat": 1458496025, > "iss": "https://security.example.com", =20 > "aud": [ > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > ], =20 > "target":{ > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > "iss": "https://scim.example.com" > }, > "events": { > "urn:ietf:params:scim:event:passwordReset": { } > } > } > =20 > Here is an example modified logout=20 > { > "iss": "https://server.example.com", > "aud": "s6BhdRkqt3", > "iat": 1471566154, > "jti": "bWJq=E2=80=9D, > =E2=80=9Ctarget=E2=80=9D:{ > "sub": "248289761001", > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D > } > "events": { > "http://schemas.openid.net/event/backchannel-logout": {} > } > } > =20 > The above formats address the following: > =20 > * Consistent structures > * Flexibility for profiles to target differently but using a common attrib= ute > * Multiple event types share a common target and must be compatible (not s= ure if this is a plus or minus) > * No conflict around SET issuer vs subject issuer > * SET is substantially different such that existing access token and ID to= ken code will reject consistently (because sub is missing) > * target could also have an attribute that indicates the target =E2=80=9Ct= ype=E2=80=9D such as SCIM resource, OP subject, IPaddress, and so on. > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > =20 --Apple-Mail-3EB99A89-1C6F-4EA2-8450-C021040D4E93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We agree on the objectives but we disa= gree on what defines simple and interoperable. 

I foresee a lot of inc= ompatibilities emerging based on the current draft. 

We have a lot of "= if this" exception logic trying to permit the OpenId specs to remain unchang= ed at the cost of clarity for general use. 

In the general, the subjec= t of events are often expressed as composites (more than one attribute). &nb= sp;The connect use of sub and iss is but one example. 

Re-using iss as= the part of the subject causes confusion outside of Connect because it appe= ars inconsistent to those that cannot take the shortcut of dual meaning use o= f iss. Within Connect causes inconsistency when RPs issue events because the= y need two iss values. One for sub and one for the set issuer. 

= IMO the spec needs a lot of clarifying language or a more universal and cons= istent way to express simple and composite subjects. 

I am looking at a= couple more options this aft for the groups consideration. 

Phil

On Jun 22, 2017, at 12:45 PM= , Mike Jones <Michael.Jone= s@microsoft.com> wrote:

It seems to me that mos= t of the discussions motiving the proposals being made have been implicitly a= ssuming that SETs are about digital identities.  In many of our use cas= es, they will be, which is great.  I fully support structing events for identity profiles to meet the needs of t= hose use cases, including often having a distinct SET issuer from the digita= l identity =E2=80=9Ciss=E2=80=9D value and having it and the digital identit= y =E2=80=9Csub=E2=80=9D be in the event structure, when needed.

 

But just like JWTs are g= reat for digital identities (consider ID Tokens) but are used in completely u= nrelated ways as well (such as Caller-ID standards), SETs should be great fo= r digital identities (consider RISC and SCIM profiles) but also be great for unrelated use cases.

 

In some use cases there= will be only one =E2=80=9Ciss=E2=80=9D and the =E2=80=9Csub=E2=80=9D may be= very different from those we use for identities.  We would be doing ev= eryone a disservice to many use cases if we tried to force that =E2=80=9Csub= =E2=80=9D and =E2=80=9Ciss=E2=80=9D be present at the event level, when those profile= s don=E2=80=99t need it there.

 

We shouldn=E2=80=99t ma= ke every SET use more complicated syntax that only more advanced use cases a= ctually need.  Therefore, we should leave the =E2=80=9Csub=E2=80=9D and= other claims descriptions as they are.  Right now it=E2=80=99s general= purpose and simple.  Let=E2=80=99s not needlessly break that.

 

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

 

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 22, 2017 12:58 PM
To: Marius Scurtescu <msc= urtescu@google.com>
Cc: ID Events Mailing List <i= d-event@ietf.org>
Subject: Re: [Id-event] Current vs. alternative subject exammples for= SEC Token Draft

 

Agreed to all your comments.  And yes, =E2=80=9C= target=E2=80=9D is not the best name.  Just can=E2=80=99t think of one a= t the moment.

 

Thanks for the additional example.  <= /p>

 

Phil

 <= /p>

Oracle Corporation, Ident= ity Cloud Services Architect & Standards

@independentid=

phil.hunt@oracle.com

 

On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <mscurtescu@google.com> wrote:<= o:p>

 

Thanks Phil, concrete examples are very useful.=

 

The top level "target" attribute is interesting, it r= educes redundancy across events (when multiple events are present in one SET= ) but it is enforcing a single profile per SET.  As you mention, not sure if this is good or bad.

 

Also, not sure about the name of the attribute, "tar= get", but I cannot come up with a better name. "target" sounds like "audienc= e". We need something along with "events subject". Maybe simply nest the "iss", "sub" and other right under "events"?

 

Here is one more example of a SET not using "sub". S= ETs between an email provider and an implicit RP would use the OIDC defined "= email" attribute (or "phone_number"):

{

   "iss": "http= s://rp.example.com",

   "aud": "s6BhdRkqt3",

   "iat": 1471566154,

=

   "jti": "bWJq",

   "events": {

       "reason": "hijacking",

       "email": "bob@example.com",

     }

   }

}

 

 

 

 


Marius

 

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

We=E2=80=99ve had a long standing thread on how to h= andle use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET.  I= =E2=80=99d like to give some examples that we can compare.=

 

Please add your comments. It would be good to reach s= ome conclusion in the next few days if we are going to change the draft for P= rague.

 

Thanks!

 

Three current draft examples:

 

1. A SCIM Event looks like:

{ 

  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",

  "iat": 1458496025,

  "aud": [

  ], &= nbsp;

  "ev= ents": {

    "urn:ietf:params:scim:event:passwordReset": { }

  }

}

 

2. An OP issued Backchannel Logout (single-sign-out)= looks like:

   {

     &n= bsp;"iss": "https://server.example.com",

     &n= bsp;"sub": "248289761001",

     &n= bsp;"aud": "s6BhdRkqt3",

     &n= bsp;"iat": 1471566154,

     &n= bsp;"jti": "bWJq",

     &n= bsp;"sid": "08a5019c-17e1-4977-8f42-65a12843ea02",<= /span>

     &n= bsp;"events": {

     &n= bsp;}

   }

 

3. An RP issued Application Logout Looks like (diffe= rent issuer):

{

   "iss": "http= s://rp.example.com",

   "aud": "s6BhdRkqt3",

   "iat": 1471566154,

   "jti": "bWJq",

   "events": {

       "sub": "248289761001",

       "iss": "https://server.example.com=E2=80=9D,

=

       "sid": "08a5019c-17e1-4977= -8f42-65a12843ea02"

    &nb= sp;}

   }

}

 

I believe the concerns here are:

 

  • Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent and m= oves around.  
  • SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its own a= ttribute in the payload (introducing more variability).  As long as =E2= =80=9Csub=E2=80=9D is valid to use in SET than profiling specs can redefine s= ub for their own purposes.  Is this good or bad?
    • Those writing parsers have to be concerned that when they are parsing a SET= they need to know the role of the server OR they have to fully parse the en= tire object to determine if they are looking at structure 2 or 3.  IOW a lot of implementations have to always chec= k for an embedded =E2=80=9Ciss=E2=80=9D to be sure they have the correct sub= ject.
  • A concern about the trade-offs if multiple event types are expressed, shoul= d they share a common top-level attribute. How does this improve or complica= te multi-type events?  In the draft, note that Figure 1 shows an event with a localized extension that adds value wit= hout impacting inter-op.
  • =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top-level. W= e=E2=80=99ve been discussing that additional attributes should be in the pay= load. Item 3 shows sid in the payload. Which is correct?

 

=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D= =3D=3D

 

A.  We could say that all SETs must embed sub a= nd iss (if they use iss for identifying subjects) in the payload.  See e= xample 3 above.  This would exclude options 1 and 2 and at least make it consistent that subject information is always in the p= ayload.  

 

B. A new top-level attribute could be defined which i= s a JSON object. Inside the JSON object, profiling specs can define how thei= r subjects are addressed. Let=E2=80=99s call it target.  A new common SET format might look something like:

 

{ 

  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",

  "iat": 1458496025,

  "aud": [

  ], &= nbsp;

  "target":{

    "iss": "https://scim.example.com"

 &n= bsp;},

  "ev= ents": {

    "urn:ietf:params:scim:event:passwordReset": { }

  }

}

 

Here is an example modified logout <= /span>

   {

      "iss": "https://server.example.com",=

      "aud": "s6BhdRkqt3",

      "iat": 1471566154,

      "jti": "bWJq=E2=80=9D,=

     &n= bsp;=E2=80=9Ctarget=E2=80=9D:{

        "sub": "248289761001",

        "sid": "08a5019c-17e= 1-4977-8f42-65a12843ea02=E2=80=9D

     &n= bsp;}

      "events": {

      }

   }

 

The above formats address the following:<= /span>

 

* Consistent structures

* Flexibility for profiles to target differently but= using a common attribute

* Multiple event types share a common target and mus= t be compatible (not sure if this is a plus or minus)

* No conflict around SET issuer vs subject issuer

* SET is substantially different such that existing a= ccess token and ID token code will reject consistently (because sub is missi= ng)

* target could also have an attribute that indicates= the target =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, IPaddr= ess, and so on.

 

Phil

 

Oracle Corporation, Identity Cloud Services Architec= t & Standards

@independentid

phil.hunt@oracle.com

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/m= ailman/listinfo/id-event

 

= --Apple-Mail-3EB99A89-1C6F-4EA2-8450-C021040D4E93-- From nobody Thu Jun 22 13:06:52 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347AD128C84 for ; Thu, 22 Jun 2017 13:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8wkqbDs3jp1 for ; Thu, 22 Jun 2017 13:06:45 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8C6127444 for ; Thu, 22 Jun 2017 13:06:44 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5MK6Yw8003299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 20:06:35 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5MK6YuW031251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 20:06:34 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5MK6VG5002509; Thu, 22 Jun 2017 20:06:31 GMT Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jun 2017 13:06:28 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-2F1B01EC-E4B5-4B33-9550-E1DD6B15E7A6 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 22 Jun 2017 13:06:25 -0700 Cc: Marius Scurtescu , "Richard Backman, Annabelle" , Henk Birkholz , Justin Richer , Yaron Sheffer , Mike Jones , John Bradley , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3! @gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <618AD3DC-778F-4C8F-B60A-92F5BDCB14F2@oracle.com> To: Benjamin Kaduk X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 20:06:50 -0000 --Apple-Mail-2F1B01EC-E4B5-4B33-9550-E1DD6B15E7A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ben, Well the event type is supposed to inform the client how to interpret its ow= n payload.=20 What we are discussing is whether SET should define subject addressing itsel= f, partially, or not at all and leave it up to the event type profile.=20 I would like to see strong standardization and consistency in the outer leve= l jwt object to improve the interop. If subject addressing is at the top lev= el then SET should be clear about its use.=20 Phil > On Jun 22, 2017, at 12:58 PM, Benjamin Kaduk wrote: >=20 > A very abstract concern I would have is that if you have some entity issui= ng SETs assuming one profile, how is it ensured that everything consuming th= ose SETs interpret it using the same profile? I know there are a lot of thi= ngs deployed out there in the greater OAuth world that use out-of-band agree= ments between participants, but maybe we want to move away from that sort of= thing. >=20 > -Ben >=20 >> On 06/21/2017 07:25 PM, Phil Hunt (IDM) wrote: >> +1 >>=20 >> Phil >>=20 >> On Jun 21, 2017, at 5:16 PM, Marius Scurtescu wro= te: >>=20 >>> On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones wrote: >>>> The proposal that I believe has the most support is keeping things as t= hey are, leaving it up to profiles and applications to define which claims t= hey use and how they use them. >>>>=20 >>>> =20 >>>>=20 >>>> It would be fine for some profiles to use the language below. >>>>=20 >>>=20 >>> I don't think this is acceptable Mike. >>>=20 >>> I'll summarize again. >>>=20 >>> We have two open problem to solve: >>> 1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in= particular). >>> 2. In some cases there is an "iss" conflict at the top level, the "sub" r= elated "iss" is different from the SET "iss". This is not specific to any pa= rticular profile. >>>=20 >>> Further, problem 1 needs a short term solution and a long term solution.= The important solution for secevent is the short term one. >>>=20 >>> Out of the above only the long term solution for problem 1 has some prom= ising resolution (using typ or cty). >>>=20 >>> So, keeping things as they are nothing relevant to secevent is solved ba= sically. >>>=20 >>> Again, if your main concern is compatibility for the logout spec (which i= s understandable) then let's talk about that and see if we can find a soluti= on for the two problems above with that constraint. Unfortunately I cannot s= ee such a solution. >>>=20 >>>=20 >>>=20 >>> =20 >>>> =20 >>>>=20 >>>> =E2=80=93 Mike >>>>=20 >>>> From: Phil Hunt >>>> Sent: Wednesday, June 21, 2017 6:39 PM >>>> To: Richard Backman, Annabelle >>>> Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin Richer; Yaron= Sheffer; Mike Jones; ID Events Mailing List >>>>=20 >>>>=20 >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and dist= inct SET issuer >>>> =20 >>>>=20 >>>> So I understand what is being proposed is: >>>>=20 >>>> If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, a= nd the issuer of the subject is identical to the issuer for the event, then =E2= =80=9Csub=E2=80=9D may be used at the top level. Otherwise, the subject of a= n event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims required to unique= ly identify the subject MUST be contained in the event payload. >>>>=20 >>>> For example, an ip address of 1.2.3.4 might be represented in a =E2=80=9C= ipaddress=E2=80=9D claim defined in the event payload. =E2=80=9Cipaddress=E2= =80=9D:=E2=80=9D1.2.3.4" >>>> A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9= a242bd3859c82c4 might be identified in the event payload as: =E2=80=9Csub=E2= =80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=E2=80= =9D >>>>=20 >>>> A Connect Logout event from an OP uses the top level sub claim and depe= nds on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the sub= ject. This means that no party may issue logout events on behalf of the OP. >>>>=20 >>>>=20 >>>> Phil >>>>=20 >>>> Oracle Corporation, Identity Cloud Services Architect & Standards >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle wrote: >>>>>=20 >>>>> Fair point. If we do not intend to support multiple profiles within a s= ingle SET, then I=E2=80=99m less concerned about leaving sub = semantics up to the profiles. >>>>> =20 >>>>> --=20 >>>>> Annabelle Richard Backman >>>>> Identity Services >>>>> =20 >>>>> =20 >>>>> From: Marius Scurtescu >>>>> Date: Wednesday, June 21, 2017 at 2:58 PM >>>>> To: "Richard Backman, Annabelle" >>>>> Cc: "Phil Hunt (IDM)" , John Bradley , Henk Birkholz , Justin Richer , Yaron Sheffer , Michael Jones , ID Events Mailing List >>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and dis= tinct SET issuer >>>>> =20 >>>>> Example for multiple events within same profile: IdP account is disabl= ed (because of hijacking), this can lead to two events: >>>>> 1. "account-disabled" >>>>> 2. "sessions-revoked" >>>>>=20 >>>>> Marius >>>>> =20 >>>>>> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle wrote: >>>>>> The spec says that the events claim SHOULD NOT be used to express mul= tiple logical events. If it=E2=80=99s also not used to express events from d= ifferent profiles that correspond to the same logical event (e.g. an OIDC ba= ckchannel logout event alongside a hypothetical RISC logout event), then I=E2= =80=99m not sure what use case that leaves for multiple events in one SET. >>>>>> =20 >>>>>> --=20 >>>>>> Annabelle Richard Backman >>>>>> Identity Services >>>>>> =20 >>>>>> =20 >>>>>> From: Id-event on behalf of "Phil Hunt (I= DM)" >>>>>> Date: Wednesday, June 21, 2017 at 2:12 PM >>>>>> To: John Bradley >>>>>> Cc: "Richard Backman, Annabelle" , Henk Birkholz= , Justin Richer , Marius S= curtescu , Yaron Sheffer , Mic= hael Jones , ID Events Mailing List >>>>>>=20 >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and di= stinct SET issuer >>>>>> =20 >>>>>> Separate or combined may be evolving. Mike wants to keep the current b= ackchannel logout very narrowly scoped. He suggested risc define its own dup= licate definitions and meanings.=20 >>>>>> =20 >>>>>> That leads me to believe we will have multi-type events in = practice. >>>>>> =20 >>>>>> Session cancellation can occur for many reasons. One of = the differentiators we had tried to= make was an assumption that user initiated events would be part of connect.= Risk would cover variations that drive off of risk calculations like passwo= rd reset.=20 >>>>>> =20 >>>>>> There are also signout events at rp's to let the OP know. These are n= ot commands but notification that a resource session is cancelled. IOW singl= e sign out not expected.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>> On Jun 21, 2017, at 1:58 PM, John Bradley wrote:= >>>>>>> I thought we decided that we are only allowing set messages form the= same family that agree on top level claims. >>>>>>> =20 >>>>>>> Otherwise there can be no top level claims and we are really definin= g a alternative format to JWT in some ways. >>>>>>> =20 >>>>>>> John B. >>>>>>> =20 >>>>>>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle wrote: >>>>>>>> =20 >>>>>>>> I agree with John that the JWT type confusion problem and the SET s= ub problem can and should be discussed separately. The secevents WG is proba= bly not the right setting to discuss the former. >>>>>>>> =20 >>>>>>>> My concern with the sub claim is that two profiles may dictate conf= licting semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B= says it=E2=80=99s an email address). If these profiles don=E2=80=99t provid= e an alternate way to declare subject of their events, then they cannot be p= resent within the same token. This incompatibility trap seems like something= that could be easily missed by groups profiling SET. >>>>>>>> =20 >>>>>>>> --=20 >>>>>>>> Annabelle Richard Backman >>>>>>>> Identity Services >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> From: John Bradley >>>>>>>> Date: Wednesday, June 21, 2017 at 1:39 PM >>>>>>>> To: Yaron Sheffer >>>>>>>> Cc: Justin Richer , Marius Scurtescu , Annabelle Richard , Phil Hunt , Michael Jones , ID Events Mailing Li= st , Henk Birkholz >>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer >>>>>>>> =20 >>>>>>>> In the envelope typ is a media/mime type. Registering application/= idt+jwt if we register jwt as a structured name sufix. =20 >>>>>>>> =20 >>>>>>>> Using the cty is also possible. I need to think about what is bet= ter but we can agree on a convention. >>>>>>>> =20 >>>>>>>> Not everything is going to be a set token like not every JWS is a J= WT. >>>>>>>> =20 >>>>>>>> If we are going to define processing rules to stop collisions and c= onfusion around JWT for different purposes, we should just start using the t= yp parameter based on the existing spec. >>>>>>>> =20 >>>>>>>> In general content sniffing if there is more than one option eventu= ally gets you into trouble. >>>>>>>> =20 >>>>>>>> I am not convinced that forcing there to be no sub at the top level= is a good idea. =20 >>>>>>>> =20 >>>>>>>> It is not the way we should differentiate between SET and id_tokens= . >>>>>>>> =20 >>>>>>>> If sub is not allowed at the top level people will do non SET JWT f= or things where the subject is scoped to the iss of the token. >>>>>>>> =20 >>>>>>>> I think defining sub to be part of the event for cases where the su= b is scoped differently from the issuer of the token is fine, but should not= be required for all event = types. >>>>>>>> =20 >>>>>>>> I think we should solve the confusion issue separately from the sub= issue. >>>>>>>> =20 >>>>>>>> Sorry I am at CIS so trying to catch up on lists. >>>>>>>> =20 >>>>>>>> John B. >>>>>>>> =20 >>>>>>>>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer = wrote: >>>>>>>>> =20 >>>>>>>>> So to summarize what I'm seeing on this thread: >>>>>>>>> Everybody agrees with Marius's short-term solution, specific rules= for "sub" and "iss" that can be defined in the SET spec. >>>>>>>>> Almost everybody agrees on a long-term "usage" claim = ("type" is taken) that should b= e defined elsewhere, e.g. in the JWT BCP. >>>>>>>>> Did I miss anything? >>>>>>>>> By the way, if we do add a "usage" claim, we need to also use it i= n the SET document before it is published. >>>>>>>>> Thanks, >>>>>>>>> Yaron >>>>>>>>> =20 >>>>>>>>>> On 15/06/17 22:08, Justin Richer wrote: >>>>>>>>>> +1 to this as well.=20 >>>>>>>>>> =20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> =20 >>>>>>>>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu wrote: >>>>>>>>>>> =20 >>>>>>>>>>> +1 to what Annabelle said.=20 >>>>>>>>>>> =20 >>>>>>>>>>> Also, Mike you are missing the other requirement, for RPs to sen= d events to an IdP. The iss+sub pair at the top level is broken in this case= . >>>>>>>>>>>=20 >>>>>>>>>>> Marius >>>>>>>>>>> =20 >>>>>>>>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) wrote: >>>>>>>>>>>> +1 >>>>>>>>>>>> =20 >>>>>>>>>>>> Phil >>>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle wrote: >>>>>>>>>>>>> Mike, >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Your explanation for why this is a non-problem is dependent up= on side effects of elements of OpenID Connect that were not designed to solv= e this issue. As a result, I see several issues with it: >>>>>>>>>>>>> 1. The caller of the Token Endpoint is the only party th= at can be certain that a nonce-less ID Token is really an ID Token. Any part= y that the caller passes the ID Token off to has no way to verify its proven= ance. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 2. Any future ID Token distribution method needs to solv= e this problem again. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D= claim. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 4. This is only a solution for ID Tokens. Every other JWT= profile that cares about disambiguation has to invent its own solution to t= he problem. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> We know from experience that naming collisions and replay atta= cks are both things that happen. What=E2=80=99s being proposed is a simple, d= efensive measure against these risks. You brought up JWT libraries: a genera= l solution actually makes it easier to use common libraries for JWT parsing.= A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, whereas with the status quo each profile would require uni= que logic. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>> Identity Services >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> From: Id-event on behalf of Mike J= ones >>>>>>>>>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>>>>>>>>> To: Marius Scurtescu >>>>>>>>>>>>> Cc: "Richard Backman, Annabelle" , ID Eve= nts Mailing List , Henk Birkholz >>>>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion= and distinct SET issuer >>>>>>>>>>>>> =20 >>>>>>>>>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D= . I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematu= re pessimation=E2=80=9D =E2=80=93 making things that can and should be simpl= e complex, without data showing there=E2=80=99s any need to do so. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Mandatory solutions are being proposed in this thread to probl= ems that there=E2=80=99s no evidence that we = actually even have. It=E2=80=99s already been es= tablished that it=E2=80=99s impossible for a SET to be confused for an ID To= ken =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg= 00428.html. If people have data showing that this is possible with specific= kinds of Access Tokens or other real JWT deployments, please provide specif= ics, so that we can use that data to inform appropriate engineering = choices on our part. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting t= he use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim= , would make previously simple things unnecessarily complex. Yes, then the r= esult is then diff= erent than a normal JWT but a consequence of this is that custom parsing cod= e would have to be used, rather than a standard JWT parser. The more unwiel= dy we make it to use SETs, the more likely developers are to just create the= ir own data structures. Keeping it simple is the key to adoption. = Standards are only useful i= f they are actually used. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> -- Mike >>>>>>>>>>>>> =20 >>>>>>>>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of= Richard Backman, Annabelle >>>>>>>>>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>>>>>>>>> To: Marius Scurtescu ; Henk Birkholz >>>>>>>>>>>>> Cc: ID Events Mailing List >>>>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion= and distinct SET issuer >>>>>>>>>>>>> =20 >>>>>>>>>>>>> Echoing Marius=E2=80=99s question: can you explain what you me= an by =E2=80=9Cintend=E2=80=9D? >>>>>>>>>>>>> =20 >>>>>>>>>>>>> To your first question, I think a better analogy would be the X= .509 Key Usage extension: a multi-valued property that declares the intended= purpose of the JWT, and that a recipient may refer to when determining whet= her to accept a JWT being presented to it in some context. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>> Identity Services >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> From: Id-event on behalf of Marius= Scurtescu >>>>>>>>>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>>>>>>>>> To: Henk Birkholz >>>>>>>>>>>>> Cc: ID Events Mailing List >>>>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion= and distinct SET issuer >>>>>>>>>>>>> =20 >>>>>>>>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz wrote: >>>>>>>>>>>>>> And a 2nd question. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What semantics would "usage" provide that that are not covere= d via "intend", "audience", and "scope"? >>>>>>>>>>>>> =20 >>>>>>>>>>>>> "aud" (audience) specifies the target client, but not the inte= nded usage (access token to authorize resource access or SET to communicate a= security event?) >>>>>>>>>>>>> =20 >>>>>>>>>>>>> "scope" is not used by SET. >>>>>>>>>>>>> =20 >>>>>>>>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>>>>>>>> =20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Henk >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT will= have a mutually exclusive set of valid claims and/or header parameters, and= enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D a= pproach to ensure that JWTs from some future spec can=E2=80=99t be mistaken f= or JWTs from a current spec. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> =C2=B7It is unrealistic to expect implementers to adhere to t= he =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. Whethe= r mandated by the spec or not, implementers will ignore this because managin= g one key is easier than managing N different keys. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80= =9D claims. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D c= laim/header parameter. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Identity Services >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> *From: *Id-event on behalf of Di= ck Hardt >>>>>>>>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>>>>>>>> *To: *Marius Scurtescu >>>>>>>>>>>>>>> *Cc: *Adam Dawes , "matake, nov" , ID Events Mailing List , "Phil Hunt (IDM)" >>>>>>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token confu= sion and distinct SET issuer >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Agreed. Note that there is still lots of discussion on what s= hould be in 3.9. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" and= the >>>>>>>>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for >>>>>>>>>>>>>>> Different Kinds of JWTs", specifically "Use different se= ts of >>>>>>>>>>>>>>> required claims...", "Use different keys for different k= inds of >>>>>>>>>>>>>>> JWTs." and "Use different issuers for different kinds of= JWTs.". >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I still think that a "type" claim would bring a lot of c= larity and >>>>>>>>>>>>>>> safety. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Marius >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>>>>>>>> http://self-issued.info/?p=3D1690 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I was initially a fan of keeping SETS to be very= similar to >>>>>>>>>>>>>>> id tokens but I now think this is a better plan.= >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +1 especially for "type" >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius Sc= urtescu >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > There were a couple of proposals on h= ow to >>>>>>>>>>>>>>> distinguish SETs from Id Tokens and Acce= ss Tokens in >>>>>>>>>>>>>>> such a way that naive implementations wi= ll not >>>>>>>>>>>>>>> confuse one for the other and open up se= curity >>>>>>>>>>>>>>> vulnerabilities. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > There is also another important requi= rement: the >>>>>>>>>>>>>>> SET issuer in some cases must be differe= nt from the >>>>>>>>>>>>>>> "sub" issuer. This is the case of an RP s= ending SETs >>>>>>>>>>>>>>> to an IdP. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > With these requirements in mind I pro= pose the >>>>>>>>>>>>>>> following: >>>>>>>>>>>>>>> > - both "sub" and "iss" to be defined a= t the event >>>>>>>>>>>>>>> level >>>>>>>>>>>>>>> > - "iss" at event level and at top SET= level can >>>>>>>>>>>>>>> be different >>>>>>>>>>>>>>> > - "iss" and "sub" at event level can b= e different >>>>>>>>>>>>>>> across events in the same SET >>>>>>>>>>>>>>> > - "sub" should NOT be present at the t= op SET >>>>>>>>>>>>>>> level (this solves the disambiguation), = please note >>>>>>>>>>>>>>> "should" and not "must" >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > This solution also allows different p= rofiles that >>>>>>>>>>>>>>> define event types to define additional c= laims >>>>>>>>>>>>>>> related to sub (like email or phone_numb= er) and >>>>>>>>>>>>>>> since all these claims will be at the ev= ent level >>>>>>>>>>>>>>> there will be no collisions or ambiguity= . >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Another proposal (which I supported) w= as to >>>>>>>>>>>>>>> define a composite "aud" claim. This is n= ot solving >>>>>>>>>>>>>>> the requirement for a distinct SET issu= er. Also, >>>>>>>>>>>>>>> having the same claim name having differ= ent syntax >>>>>>>>>>>>>>> in different token types could lead to c= onfusion. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > And yet another proposal was to intro= duce a new >>>>>>>>>>>>>>> claim for JWTs that defines a "type". Th= is is not >>>>>>>>>>>>>>> practical in the short term, and it also= is not >>>>>>>>>>>>>>> solving the distinct issuer requirement,= but I think >>>>>>>>>>>>>>> this is something the JWT group should s= eriously >>>>>>>>>>>>>>> consider. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Thoughts? >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Marius >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> > _____________________________________= __________ >>>>>>>>>>>>>>> > Id-event mailing list >>>>>>>>>>>>>>> > Id-event@ietf.org >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url= ?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1Y= umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlN= Ke4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9= NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ________________________________________= _______ >>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id= -event >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ____________________________________________= ___ >>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>> Id-event@ietf.org = >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-eve= nt >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>> Adam Dawes | Sr. Product Manager |adawes@google.= com >>>>>>>>>>>>>>> |+1 650-214-2410 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>> Subscribe to the HARDTWARE m= ail list to >>>>>>>>>>>>>>> learn about projects I am working on! >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> --=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Subscribe to the HARDTWARE mail list= to learn about projects I am working on! >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU= 7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7= TmGMSWWs&e=3D >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>=20 >>>>>>>> =20 >>>>>>>=20 >>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>=20 >>>>> =20 >>>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DBdig6jCQcXk91JEeOcs= SzadVRk9IgwZ5HRkh8f0EjfA&s=3DPnOQEkjo50Ss_9xMzvLfAShD4e4QDhX6LsSMHSX0f8Q&e=3D= =20 --Apple-Mail-2F1B01EC-E4B5-4B33-9550-E1DD6B15E7A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ben,

Well the event type is supposed t= o inform the client how to interpret its own payload. 

What we are dis= cussing is whether SET should define subject addressing itself, partially, o= r not at all and leave it up to the event type profile. 

I would like t= o see strong standardization and consistency in the outer level jwt object t= o improve the interop. If subject addressing is at the top level then SET sh= ould be clear about its use. 

Phil

On Jun 22, 2017= , at 12:58 PM, Benjamin Kaduk <bkadu= k@akamai.com> wrote:

=20 =20 =20 =20 A very abstract concern I would have is that if you have some entity issuing SETs assuming one profile, how is it ensured that everything consuming those SETs interpret it using the same profile?  I know there are a lot of things deployed out there in the greater OAuth world that use out-of-band agreements between participants, but maybe we want to move away from that sort of thing.

-Ben

On 06/21/2017 07:25 PM, Phil Hunt (IDM) wrote:
=20
+1

Phil

On Jun 21, 2017, at 5:16 PM, Marius Scurtescu <mscurtescu@google.com>= ; wrote:

On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The proposal that I believe has the most support is keeping things as they are, leaving it up to profiles and applications to define which claims they use and how they use them.

 

It would be fine for some profiles to use the language below.


I don't think this is acceptable Mike.

I'll summarize again.

We have two open problem to solve:
1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in particular).
2. In some cases there is an "iss" conflict at the top level, the "sub" related "iss" is different from the SET "iss". This is not specific to any particular profile.

Further, problem 1 needs a short term solution and a long term solution. The important solution for secevent is the short term one.

Out of the above only the long term solution for problem 1 has some promising resolution (using typ or cty).

So, keeping things as they are nothing relevant to secevent is solved basically.

Again, if your main concern is compatibility for the logout spec (which is understandable) then let's talk about that and see if we can find a solution for the two problems above with that constraint. Unfortunately I cannot see such a solution.



 

 

=E2=80=93 Mike

From: Phil Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtes= cu; John Bradley; Henk Birkholz; Justin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List


Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

 

So I understand what is being proposed is:

If the event type uses =E2=80=9Csub=E2=80=9D to identify it= s subject, and the issuer of the subject is identical to the issuer for the event, then =E2=80=9Csub= =E2=80=9D may be used at the top level. Otherwise, the subject of an event (e.g. =E2=80=9Csub=E2=80= =9D) and any other claims required to uniquely identify the subject MUST be contained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a =E2=80=9Cipaddress=E2=80= =9D claim defined in the event payload. =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1fa= ebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload as: =E2=80=9Csub=E2=80=9D:"https://sci= m.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=E2=80= =9D

A Connect Logout event from an OP uses the top level sub claim and depends on =E2=80=9C= iss=E2=80=9D being the same for the event issuer AND the subject. This means that no party may issue logout events on behalf of the OP.


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independenti= d
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Fair point. If we do not intend to support multiple profiles within a single SET, then I=E2=80=99m less concerned about leaving sub semantics up to the profiles.=
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Mari= us Scurtescu <mscurtescu@google.com>
Date: Wednesday, June 21, 2017 at 2:58 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: "Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
Example for multiple events within same profile: IdP account is disabled (because of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the events claim SHOULD NOT be used to express multiple logical events. If it=E2=80=99s al= so not used to express events from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then I=E2=80=99m not sure what u= se case that leaves for multiple events in one SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM)" <phil.hunt@ora= cle.com>
Date: Wednesday, June 21, 2017 at 2:12 PM
To: John Bradley <ve7jtb@ve7jtb.com<= /a>>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com&g= t;, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.ed= u>, Marius Scurtescu <mscurtescu@google.com<= /a>>, Yaron Sheffer <yaronf.i= etf@gmail.com>, Michael Jones <Mi= chael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org= >

Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
Separate or combined may be evolving. Mike wants to keep the current backchannel logout very narrowly scoped. He suggested risc define its own duplicate definitions and meanings. 
 
That leads me to believe we will have multi-type events in practice.
 
Session cancellation can occur for many reasons. One of the differentiators we had tried to make was an assumption that user initiated events would be part of connect. Risk would cover variations that drive off of risk calculations like password reset. <= /div>
 
There are also signout events at rp's to let the OP know. These are not commands but notification that a resource session is cancelled. IOW single sign out not expected. 

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com<= /a>> wrote:
I thought we decided that we are only allowing set messages form the same family that agree on top level claims.
 
Otherwise there can be no top level claims and we are really defining a alternative format to JWT in some ways.
 
John B.
 
 
I agree with John that the JWT type confusion problem and the SET sub problem can and should be discussed separately. The secevents WG is probably not the right setting to discuss the former.
 
My concern with the sub claim is that two profiles may dictate conflicting semantics (e.g. Profile A says it=E2=80=99= s a phone number, Profile B says it=E2=80=99s an em= ail address). If these profiles don=E2=80=99t prov= ide an alternate way to declare subject of their events, then they cannot be present within the same token. This incompatibility trap seems like something that could be easily missed by groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: <= /span>Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.i= etf@gmail.com>
Cc: Justin Richer <jricher@mit.edu= >, Marius Scurtescu <mscurt= escu@google.com>, Annabelle Richard <richanna@a= mazon.com>, Phil Hunt <phil.hu= nt@oracle.com>, Michael Jones <Michael.Jo= nes@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>=
Subject:&nbs= p;Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
In the envelope typ is a media/mime type.  Registering application/idt+jw= t if we register jwt as a structured name sufix.  =
 
Using the cty is also possible.   I= need to think about what is better but we can agree on a convention.
 
Not everything is going to be a set token like not every JWS is a JWT.
 
If we are going to define processing rules to stop collisions and confusion around JWT for different purposes, we should just start using the typ parameter based on the existing spec.
 
In general content sniffing if there is more than one option eventually gets you into trouble.
 
I am not convinced that forcing there to be no sub at the top level is a good idea.  <= /div>
 
It is not the way we should differentiate between SET and id_tokens.
 
If sub is not allowed at the top level people will do non SET JWT for things where the subject is scoped to the iss of the token.
 
I think defining sub to be part of the event for cases where the sub is scoped differently from the issuer of the token is fine, but should not be required for all event types.
 
I think we should solve the confusion issue separately from the sub issue.
 
Sorry I am at CIS so trying to catch up on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
So to summarize what I'm seeing on this thread:
=
Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.
Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.
Thanks,
   = Yaron
 
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well. 
 
 =E2=80=94 Ju= stin
 
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what Annabelle said. 
 
Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

=
Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
=
 
=
Phil

 

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
 
Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.=

2.       Any future ID Token distribution method needs to solve this problem again.

3. &n= bsp;    No other profile of JWT can ever use the "nonce=E2=80=9D cl= aim.

4. &n= bsp;    This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

 
We know from experience that naming collisions and replay attacks are both things that happen. What=E2=80= =99s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A =E2=80=9Cusage-awa= re=E2=80=9D JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: <= /span>Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Subject:&nbs= p;Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
You=E2=80=99ve heard of =E2=80=9Cpremature= optimization=E2=80= =9D.  I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cpremat= ure pessimation=E2=80=9D= =E2=80=93 making things that can and should be simple complex, without data showing there=E2=80=99s an= y need to do so.
 
Mandatory solutions are being proposed in this thread to problems that there=E2=80=99= s no evidence that we actually even have.  It=E2=80= =99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80= =93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
=
 
The proposed =E2=80=9Csolutions= =E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2=80= =9D in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.  Yes= , then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser.  The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key to adoption.  Standards are only useful if they are actually used.
 
    &nbs= p;            &n= bsp;            =             = ;      -- Mike
 =
From: Id-event [mailto:id-event-bounces@ietf.org]&nbs= p;On Behalf Of = Richard Backman, Annabelle
Sent:&nbs= p;Tuesday, June 13, 2017 5:33 PM
To: = ;Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Cc: = ;ID Events Mailing List <id-event@ietf.org>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80=9Cintend= =E2=80=9D?
 
To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date: <= /span>Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de<= /a>>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject:&nbs= p;Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
 
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<= /a>> wrote:
And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?
=
 
"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)
 
"scope" is not used by SET.
=
 
I don't know what do you mean by "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80= =99t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a =E2=80=9Cfail on= an unrecognized claim=E2=80=9D approach to ensure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdiffe= rent keys for different kinds of JWTs=E2=80= =9D rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80= =9D and =E2=80=9Ciss=E2=80= =9D claims.

+1 for a =E2=80=9Ctype=E2=80= =9D or =E2=80=9Cusage=E2=80= =9D claim/header parameter.

-- =

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Than= ks for the pointer Dick, very good timing :-)

    The i= ssue is described by "2.7. Cross-JWT Confusion" and the
    miti= gation is in "3.9. Use Mutually Exclusive Validation Rules for
    Diff= erent Kinds of JWTs", specifically "Use different sets of
    requ= ired claims...", "Use different keys for different kinds of
    JWTs= ." and "Use different issuers for different kinds of JWTs.".

    I st= ill think that a "type" claim would bring a lot of clarity and
    safe= ty.


    Mari= us

    On T= hu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
    <mailto:dick.hardt@gmail.com>> wrote:

    &nbs= p;   Yaron, Mike and I just published an BCP ID for JWT
    &nbs= p;   http://self-issued.info/?p=3D1690

    &nbs= p;   On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
    &nbs= p;   <mailto:adawes@google.com>> wrote:

    &nbs= p;       I was initially a fan of keeping SETS to be very similar to
    &nbs= p;       id tokens but I now think this is a better plan.

    &nbs= p;       On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
    &nbs= p;       <mailto:nov@matake.jp>> wrote:

    &nbs= p;           +1 especially for "type"

    &nbs= p;           2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
    &nbs= p;           <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

    &nbs= p;             &nbs= p; +1

    &nbs= p;             &nbs= p; Phil


    &nbs= p;             &nbs= p;  > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
    &nbs= p;             &nbs= p; <mscurtescu@google.com
    &nbs= p;             &nbs= p; <mailto:mscurtescu@google.com>> wrote:
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > There were a couple of proposals on how to
    &nbs= p;             &nbs= p; distinguish SETs from Id Tokens and Access Tokens in
    &nbs= p;             &nbs= p; such a way that naive implementations will not
    &nbs= p;             &nbs= p; confuse one for the other and open up security
    &nbs= p;             &nbs= p; vulnerabilities.     &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > There is also another important requirement: the
    &nbs= p;             &nbs= p; SET issuer in some cases must be different from the
    &nbs= p;             &nbs= p; "sub" issuer. This is the case of an RP sending SETs
    &nbs= p;             &nbs= p; to an IdP.
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > With these requirements in mind I propose the
    &nbs= p;             &nbs= p; following:
    &nbs= p;             &nbs= p;  > - both "sub" and "iss" to be defined at the event
    &nbs= p;             &nbs= p; level
    &nbs= p;             &nbs= p;  > - "iss" at event level and at top SET level can
    &nbs= p;             &nbs= p; be different
    &nbs= p;             &nbs= p;  > - "iss" and "sub" at event level can be different
    &nbs= p;             &nbs= p; across events in the same SET
    &nbs= p;             &nbs= p;  > - "sub" should NOT be present at the top SET
=     &nbs= p;             &nbs= p; level (this solves the disambiguation), please note
    &nbs= p;             &nbs= p; "should" and not "must"
=     &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > This solution also allows different profiles that
    &nbs= p;             &nbs= p; define event types to define additional claims
    &nbs= p;             &nbs= p; related to sub (like email or phone_number) and
    &nbs= p;             &nbs= p; since all these claims will be at the event level
    &nbs= p;             &nbs= p; there will be no collisions or ambiguity.
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > Another proposal (which I supported) was to
    &nbs= p;             &nbs= p; define a composite "aud" claim. This is not solving
    &nbs= p;             &nbs= p; the requirement for a distinct  SET= issuer. Also,
    &nbs= p;             &nbs= p; having the same claim name having different syntax
    &nbs= p;             &nbs= p; in different token types could lead to confusion.
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > And yet another proposal was to introduce a new
    &nbs= p;             &nbs= p; claim for JWTs that defines a "type". This is not
    &nbs= p;             &nbs= p; practical in the short term, and it also is not
    &nbs= p;             &nbs= p; solving the distinct issuer requirement, but I think
    &nbs= p;             &nbs= p; this is something the JWT group should seriously
    &nbs= p;             &nbs= p; consider.
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > Thoughts?
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p;  > Marius

    &nbs= p;             &nbs= p;  > __________________= _____________________________
    &nbs= p;             &nbs= p;  > Id-event mailing list
=

    &nbs= p;             &nbs= p;  > Id-event@ietf.org=  <mailto:Id-event@ietf.org<= /span>>
    &nbs= p;             &nbs= p;  >
    &nbs= p;             &nbs= p; https://urldefense.proofpoint.c= om/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&a= mp;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D<= wbr>JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6= Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

    &nbs= p;             &nbs= p; __________________= _____________________________
    &nbs= p;             &nbs= p; Id-event mailing list
    &nbs= p;             &nbs= p; Id-event@ietf.org&nbs= p;<mailto:Id-event@ietf.org= >
    &nbs= p;             &nbs= p; https://www.ietf.org/mailman/li= stinfo/id-event

    &nbs= p;           __________________= _____________________________
    &nbs= p;           Id-event mailing list
    &nbs= p;           Id-event@ietf.org <mai= lto:Id-event@ietf.org>
    &nbs= p;           https://www.ietf.org/mailman/listinfo/id-event<= /span>

    &nbs= p;       -- 
    &nbs= p;       Adam Dawes | Sr. Product Manager |adawes@google.com
    &nbs= p;       <mailto:adawes@google.com> |+1 650-214-2410
    &nbs= p;       <tel:(650)%20214-2410>

    &nbs= p;       __________________= _____________________________
    &nbs= p;       Id-event mailing list
    &nbs= p;       Id-event@ietf.o= rg <mailto:Id-event= @ietf.org>
    &nbs= p;       https://www.ietf.= org/mailman/listinfo/id-event

    &nbs= p;   -- 
    &nbs= p;   Subscribe to the HARDTWARE <http://hardtware.co= m/> mail list to
    &nbs= p;   learn about projects I am working on!



-- =

Subscribe to the HARDTWARE <http://hardtware.co= m/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 




_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-=
event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mail= man/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailma= n/listinfo/id-event
 




_______________________________________________
Id-event mailing list
Id-e=
vent@ietf.org
https://=
www.ietf.org/mailman/listinfo/id-event

=20
= --Apple-Mail-2F1B01EC-E4B5-4B33-9550-E1DD6B15E7A6-- From nobody Thu Jun 22 14:30:49 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C89C129B79 for ; Thu, 22 Jun 2017 14:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIX_pSOGgxCm for ; Thu, 22 Jun 2017 14:30:43 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E3F1294B3 for ; Thu, 22 Jun 2017 14:30:43 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m47so27501395iti.0 for ; Thu, 22 Jun 2017 14:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W9HE595fYkrxgFAHtc0RimzJt25zvfY6Te/2fCGh8KE=; b=N/6bo/B/N9XHTLLeBLsRJ74HM+sbRErpVSs/uS+DrVtCMVrEQPuGaapKcaYrA67V1T CtXAxlEv2Rp2hmlVeLvmPIxBE6Szr+Q/VrXsMKkyVHjDCBsc+GVRVzyxbMRfv1s+8o+y oBFXKfdEq7mHlqEFvrIQFdkxVf4nbxLMQH8QZG8AwUDTFKa7MFf5o3caoel8p/EU7OSv PDOekBOp7SI/WWle8sPUWV+8xLNGcZYF2+WhwpQ3c7mo+L1okfHdL0QxNqt/RR//AlGO RvxmFjS9tZ51MH45dDDdVqv7o/Td7x8i0XEEp0SnaIm+3vqRcvUZc8z3azVMV6rmuDB7 Cwxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W9HE595fYkrxgFAHtc0RimzJt25zvfY6Te/2fCGh8KE=; b=JlS/lnhAVSZZDRtucdw41OQNMEGeiavjT/L1c7z1dsF7gttS1tjkV1BncERnHhoAvE OTYLdvv1OijP6iBwH33BE/kv8ge5v55XMnAD8L0SmaaSPFlR2M/i+VdriCrMXxWp8xet HUDLJ6eCAPy7VwRHEIeW29EEeekxDVdZHnGfrlRCHQnP4x2eboandB9hFqGoJ/bgH3J0 MUH5psEftircMobgL48BQAGo0ZIly2tWTH6ptVw+rVXpzdpYvpXHxc6PlzqXapVmTrrs vC6BF+hAUDa4knFaTZ15RXFwmZxTZFjYDm56Ja84ylhF6QhmAGWgZu2LMBd5YFvEtrx1 rvvw== X-Gm-Message-State: AKS2vOwnAu1TO6T/Cnp0cYYnJNo/QD+bRCw4TcR2cAdNz701PxtE43Gh 9iD71W/3s3usXWh/evtVyud4+ExqAPsG X-Received: by 10.36.217.207 with SMTP id p198mr4346354itg.116.1498167042268; Thu, 22 Jun 2017 14:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 22 Jun 2017 14:30:21 -0700 (PDT) In-Reply-To: References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> From: Marius Scurtescu Date: Thu, 22 Jun 2017 14:30:21 -0700 Message-ID: To: Mike Jones Cc: Phil Hunt , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a113718b25ef44c0552933214" Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 21:30:47 -0000 --001a113718b25ef44c0552933214 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Digital identities were an implicit assumption, definitely for me, and we should make sure that SETs can be profiled for other use cases as well (for example networking protocols). Thanks for clarifying this Mike. At the same time, digital identities are the main driver of requirements for security events, we have to make sure SETs are a good fit for them. Having the SET spec on its own being both insecure (the confusion problem) and not covering all uses cases (RP created SETs) does not sound right to me. Asking each profile to address these issues is not reasonable in my view. The solutions proposed so far do not prevent in any way non-digital identity profiles. As Phil mentioned, I think the main disagreement is around the level of complexity. Another smaller disagreement to me is considering digital identity use cases as advanced or special. To me these are the main use cases, I would like to see a solid solution for them. All that being said, I think we made good progress on today's call and I am sure that face to face meetings will help a lot. Looking forward to crack these issues in Prague. Marius On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones wrote: > It seems to me that most of the discussions motiving the proposals being > made have been implicitly assuming that SETs are about digital identities= . > In many of our use cases, they will be, which is great. I fully support > structing events for identity profiles to meet the needs of those use > cases, including often having a distinct SET issuer from the digital > identity =E2=80=9Ciss=E2=80=9D value and having it and the digital identi= ty =E2=80=9Csub=E2=80=9D be in the > event structure, when needed. > > > > But just like JWTs are great for digital identities (consider ID Tokens) > but are used in completely unrelated ways as well (such as Caller-ID > standards), SETs should be great for digital identities (consider RISC an= d > SCIM profiles) but also be great for unrelated use cases. > > > > In some use cases there will be only one =E2=80=9Ciss=E2=80=9D and the = =E2=80=9Csub=E2=80=9D may be very > different from those we use for identities. We would be doing everyone a > disservice to many use cases if we tried to force that =E2=80=9Csub=E2=80= =9D and =E2=80=9Ciss=E2=80=9D be > present at the event level, when those profiles don=E2=80=99t need it the= re. > > > > We shouldn=E2=80=99t make every SET use more complicated syntax that only= more > advanced use cases actually need. Therefore, we should leave the =E2=80= =9Csub=E2=80=9D and > other claims descriptions as they are. Right now it=E2=80=99s general pu= rpose and > simple. Let=E2=80=99s not needlessly break that. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] * On Behalf Of *Phil > Hunt > *Sent:* Thursday, June 22, 2017 12:58 PM > *To:* Marius Scurtescu > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] Current vs. alternative subject exammples for > SEC Token Draft > > > > Agreed to all your comments. And yes, =E2=80=9Ctarget=E2=80=9D is not th= e best name. > Just can=E2=80=99t think of one at the moment. > > > > Thanks for the additional example. > > > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect & Standards > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > On Jun 22, 2017, at 10:53 AM, Marius Scurtescu > wrote: > > > > Thanks Phil, concrete examples are very useful. > > > > The top level "target" attribute is interesting, it reduces redundancy > across events (when multiple events are present in one SET) but it is > enforcing a single profile per SET. As you mention, not sure if this is > good or bad. > > > > Also, not sure about the name of the attribute, "target", but I cannot > come up with a better name. "target" sounds like "audience". We need > something along with "events subject". Maybe simply nest the "iss", "sub" > and other right under "events"? > > > > Here is one more example of a SET not using "sub". SETs between an email > provider and an implicit RP would use the OIDC defined "email" attribute > (or "phone_number"): > > { > > "iss": "https://rp.example.com", > > "aud": "s6BhdRkqt3", > > "iat": 1471566154, > > "jti": "bWJq", > > "events": { > > "http://schemas.openid.net/event/risc//account-disabled > ": > { > > "reason": "hijacking", > > "email": "bob@example.com", > > } > > } > > } > > > > > > > > > > > Marius > > > > On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt wrote: > > We=E2=80=99ve had a long standing thread on how to handle use of =E2=80= =9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D > in SET. I=E2=80=99d like to give some examples that we can compare. > > > > Please add your comments. It would be good to reach some conclusion in th= e > next few days if we are going to change the draft for Prague. > > > > Thanks! > > > > Three current draft examples: > > > > 1. A SCIM Event looks like: > > { > > "*jti*": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "*iat*": 1458496025, > > "*iss*": "https://security.example.com", > > "*aud*": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > > "events": { > > "urn:ietf:params:scim:event:passwordReset": { } > > } > > } > > > > 2. An OP issued Backchannel Logout (single-sign-out) looks like: > > { > > "*iss*": "https://server.example.com", > > "sub": "248289761001", > > "*aud*": "s6BhdRkqt3", > > "*iat*": 1471566154, > > "*jti*": "bWJq", > > "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02", > > "events": { > > "http://schemas.openid.net/event/backchannel-logout > ": > {} > > } > > } > > > > 3. An RP issued Application Logout Looks like (different issuer): > > { > > "*iss*": "https://rp.example.com", > > "*aud*": "s6BhdRkqt3", > > "*iat*": 1471566154, > > "*jti*": "bWJq", > > "events": { > > "http://schemas.openid.net/event/risc-logout > ": > { > > "sub": "248289761001", > > "*iss*": "https://server.example.com=E2=80=9D, > > "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02" > > } > > } > > } > > > > I believe the concerns here are: > > > > - Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsiste= nt and moves around. > - SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use i= ts own attribute > in the payload (introducing more variability). As long as =E2=80=9Csu= b=E2=80=9D is valid > to use in SET than profiling specs can redefine sub for their own > purposes. Is this good or bad? > - Those writing parsers have to be concerned that when they are > parsing a SET they need to know the role of the server OR they have to > fully parse the entire object to determine if they are looking at stru= cture > 2 or 3. IOW a lot of implementations have to always check for an embe= dded > =E2=80=9Ciss=E2=80=9D to be sure they have the correct subject. > - A concern about the trade-offs if multiple event types are > expressed, should they share a common top-level attribute. How does th= is > improve or complicate multi-type events? In the draft, note that Figu= re 1 > shows an event with a localized extension that adds value without impa= cting > inter-op. > - =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top-= level. We=E2=80=99ve > been discussing that additional attributes should be in the payload. I= tem 3 > shows sid in the payload. Which is correct? > > > > =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D > > > > A. We could say that all SETs must embed sub and iss (if they use iss fo= r > identifying subjects) in the payload. See example 3 above. This would > exclude options 1 and 2 and at least make it consistent that subject > information is always in the payload. > > > > B. A new top-level attribute could be defined which is a JSON object. > Inside the JSON object, profiling specs can define how their subjects are > addressed. Let=E2=80=99s call it target. A new common SET format might l= ook > something like: > > > > { > > "*jti*": "3d0c3cf797584bd193bd0fb1bd4e7d30", > > "*iat*": 1458496025, > > "*iss*": "https://security.example.com", > > "*aud*": [ > > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", > > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" > > ], > > "target":{ > > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", > > "*iss*": "https://scim.example.com" > > }, > > "events": { > > "urn:ietf:params:scim:event:passwordReset": { } > > } > > } > > > > Here is an example modified logout > > { > > "*iss*": "https://server.example.com", > > "*aud*": "s6BhdRkqt3", > > "*iat*": 1471566154, > > "*jti*": "bWJq=E2=80=9D, > > =E2=80=9Ctarget=E2=80=9D:{ > > "sub": "248289761001", > > "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D > > } > > "events": { > > "http://schemas.openid.net/event/backchannel-logout > ": > {} > > } > > } > > > > The above formats address the following: > > > > * Consistent structures > > * Flexibility for profiles to target differently but using a common > attribute > > * Multiple event types share a common target and must be compatible (not > sure if this is a plus or minus) > > * No conflict around SET issuer vs subject issuer > > * SET is substantially different such that existing access token and ID > token code will reject consistently (because sub is missing) > > * target could also have an attribute that indicates the target =E2=80=9C= type=E2=80=9D > such as SCIM resource, OP subject, IPaddress, and so on. > > > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect & Standards > > @independentid > > www.independentid.com > > > phil.hunt@oracle.com > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > --001a113718b25ef44c0552933214 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Digi= tal identities were an implicit assumption, definitely for me, and we shoul= d make sure that SETs can be profiled for other use cases as well (for exam= ple networking protocols). Thanks for clarifying this Mike.

At the same time, dig= ital identities are the main driver of requirements for security events, we= have to make sure SETs are a good fit for them. Having the SET spec on its= own being both insecure (the confusion problem) and not covering all uses = cases (RP created SETs) does not sound right to me. Asking each profile to = address these issues is not reasonable in my view.

The solutions proposed so far = do not prevent in any way non-digital identity profiles.

As Phil mentioned, I thi= nk the main disagreement is around the level of complexity. Another smaller= disagreement to me is considering digital identity use cases as advanced o= r special. To me these are the main use cases, I would like to see a solid = solution for them.

All that being said, I think we made good progress on today= 9;s call and I am sure that face to face meetings will help a lot. Looking = forward to crack these issues in Prague.
Marius
<= br>

On= Thu, Jun 22, 2017 at 12:45 PM, Mike Jones <Mic= hael.Jones@microsoft.com> wrote:

It seems to me that mo= st of the discussions motiving the proposals being made have been implicitl= y assuming that SETs are about digital identities.=C2=A0 In many of our use= cases, they will be, which is great.=C2=A0 I fully support structing events for identity profiles to meet the needs of = those use cases, including often having a distinct SET issuer from the digi= tal identity =E2=80=9Ciss=E2=80=9D value and having it and the digital iden= tity =E2=80=9Csub=E2=80=9D be in the event structure, when needed.

=C2=A0

But just like JWTs are= great for digital identities (consider ID Tokens) but are used in complete= ly unrelated ways as well (such as Caller-ID standards), SETs should be gre= at for digital identities (consider RISC and SCIM profiles) but also be great for unrelated use cases.<= u>

=C2=A0

In some use cases ther= e will be only one =E2=80=9Ciss=E2=80=9D and the =E2=80=9Csub=E2=80=9D may = be very different from those we use for identities.=C2=A0 We would be doing= everyone a disservice to many use cases if we tried to force that =E2=80= =9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D be present at the event level, when those profil= es don=E2=80=99t need it there.

=C2=A0

We shouldn=E2=80=99t m= ake every SET use more complicated syntax that only more advanced use cases= actually need.=C2=A0 Therefore, we should leave the =E2=80=9Csub=E2=80=9D = and other claims descriptions as they are.=C2=A0 Right now it=E2=80=99s gen= eral purpose and simple.=C2=A0 Let=E2=80=99s not needlessly break that.<= u>

=C2=A0

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

=C2=A0

From: Id-event [mailto:id-event-bounces@= ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 22, 2017 12:58 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Current vs. alternative subject exammples fo= r SEC Token Draft

=C2=A0

Agreed to all your comments.=C2=A0 And yes, =E2=80= =9Ctarget=E2=80=9D is not the best name.=C2=A0 Just can=E2=80=99t think of = one at the moment.

=C2=A0

Thanks for the additional example. =C2=A0<= /u>

=C2=A0

Phil

=C2=A0

Oracle Corporation, Iden= tity Cloud Services Architect & Standards

@independentid=

phil.hunt@oracle.com=

=C2=A0

On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com> wrote:

=C2=A0

Thanks Phil, concrete examples are very useful.=

=C2=A0

The top level "target" attribute is inte= resting, it reduces redundancy across events (when multiple events are pres= ent in one SET) but it is enforcing a single profile per SET.=C2=A0 As you mention, not sure if this is good or bad.<= /span>

=C2=A0

Also, not sure about the name of the attribute, &q= uot;target", but I cannot come up with a better name. "target&quo= t; sounds like "audience". We need something along with "eve= nts subject". Maybe simply nest the "iss", "sub" and other right und= er "events"?

=C2=A0

Here is one more example of a SET not using "= sub". SETs between an email provider and an implicit RP would use the = OIDC defined "email" attribute (or "phone_number"):<= /u>

{

=C2=A0 =C2=A0"iss": "https://rp.example.com&= quot;,

=C2=A0 =C2=A0"aud": "s6BhdRkqt3",

=C2=A0 =C2=A0"iat": 1471566154,

=C2=A0 =C2=A0"jti": "bWJq",=

=C2=A0 =C2=A0"events": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0"reason": "hijack= ing",

=C2=A0 =C2=A0 =C2=A0 =C2=A0"email": "bob@example.= com",

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

}

=C2=A0

=C2=A0

=C2=A0

=C2=A0


Marius

=C2=A0

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt=C2=A0<phil.h= unt@oracle.com>=C2=A0wrote:

We=E2=80=99ve had a long standing thread on how to= handle use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET.=C2= =A0 I=E2=80=99d like to give some examples that we can compare.

=C2=A0

Please add your comments. It would be good to reac= h some conclusion in the next few days if we are going to change the draft = for Prague.

=C2=A0

Thanks!

=C2=A0

Three current draft examples:=

=C2=A0

1. A SCIM Event looks like:

{=C2=A0

=C2=A0=C2=A0"jti": "3d0c3cf797584bd193bd= 0fb1bd4e7d30",

=C2=A0=C2=A0"iat": 1458496025,

=C2=A0=C2=A0"iss": "https://security.exampl= e.com", =C2=A0

=C2=A0=C2=A0"aud": [

=C2=A0=C2=A0], =C2=A0

=C2=A0=C2=A0"events": {

=C2=A0 =C2=A0=C2=A0"urn:ietf:params:scim:event:passwordRe= set": { }

=C2=A0=C2=A0}

}

=C2=A0

2. An OP issued Backchannel Logout (single-sign-ou= t) looks like:

=C2=A0 =C2=A0{

=C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https://ser= ver.example.com",

=C2=A0 =C2=A0 =C2=A0=C2=A0"sub": "248289761001"= ,

=C2=A0 =C2=A0 =C2=A0=C2=A0"aud": "s6BhdRkqt3&= quot;,

=C2=A0 =C2=A0 =C2=A0=C2=A0"iat": 1471566154,

=C2=A0 =C2=A0 =C2=A0=C2=A0"jti": "bWJq",=

=C2=A0 =C2=A0 =C2=A0=C2=A0"sid": "08a5019c-17= e1-4977-8f42-65a12843ea02",

=C2=A0 =C2=A0 =C2=A0=C2=A0"events": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"http://schemas.openid.ne= t/event/backchannel-logout": {}

=C2=A0 =C2=A0 =C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0}

=C2=A0

3. An RP issued Application Logout Looks like (dif= ferent issuer):

{

=C2=A0=C2=A0=C2=A0"iss": "https://rp.example.com<= /a>",

=C2=A0=C2=A0=C2=A0"aud": "s6BhdRkqt3",

=C2=A0=C2=A0=C2=A0"iat": 1471566154,=

=C2=A0=C2=A0=C2=A0"jti": "bWJq",<= u>

=C2=A0=C2=A0=C2=A0"events": {

=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0"sub": "248289761001= ",

=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https= ://server.example.com=E2=80=9D,

=C2=A0 =C2=A0 =C2=A0 =C2=A0"sid": "0= 8a5019c-17e1-4977-8f42-65a12843ea02"

=C2=A0=C2=A0 =C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0}

}

=C2=A0

I believe the concerns here are:

=C2=A0

  • Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent an= d moves around. =C2=A0
  • SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its ow= n attribute in the payload (introducing more variability).=C2=A0 As long as= =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can rede= fine sub for their own purposes.=C2=A0 Is this good or bad?
  • Those writing parsers have to be concerned that when they are parsing a S= ET they need to know the role of the server OR they have to fully parse the= entire object to determine if they are looking at structure 2 or 3.=C2=A0 IOW a lot of implementations have to always che= ck for an embedded =E2=80=9Ciss=E2=80=9D to be sure they have the correct s= ubject.
  • A concern about the trade-offs if multiple event types are expressed, sho= uld they share a common top-level attribute. How does this improve or compl= icate multi-type events?=C2=A0 In the draft, note that Figure 1 shows an event with a localized extension that adds value wi= thout impacting inter-op.
  • =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top-level= . We=E2=80=99ve been discussing that additional attributes should be in the= payload. Item 3 shows sid in the payload. Which is correct?<= /span>

=C2=A0

=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D= =3D=3D=3D

=C2=A0

A.=C2=A0 We could say that all SETs must embed sub= and iss (if they use iss for identifying subjects) in the payload.=C2=A0 S= ee example 3 above.=C2=A0 This would exclude options 1 and 2 and at least make it consistent that subject information is always in the = payload. =C2=A0

=C2=A0

B. A new top-level attribute could be defined whic= h is a JSON object. Inside the JSON object, profiling specs can define how = their subjects are addressed. Let=E2=80=99s call it target.=C2=A0 A new common SET format might look something like:

=C2=A0

{=C2=A0

=C2=A0=C2=A0"jti": "3d0c3cf797584bd193bd= 0fb1bd4e7d30",

=C2=A0=C2=A0"iat": 1458496025,

=C2=A0=C2=A0"iss": "https://security.exampl= e.com", =C2=A0

=C2=A0=C2=A0"aud": [

=C2=A0=C2=A0], =C2=A0

=C2=A0=C2=A0"target":{

=C2=A0 =C2=A0=C2=A0"iss": "https:= //scim.example.com"

=C2=A0=C2=A0},

=C2=A0=C2=A0"events": {

=C2=A0 =C2=A0=C2=A0"urn:ietf:params:scim:event:passwordRe= set": { }

=C2=A0=C2=A0}

}

=C2=A0

Here is an example modified logout=C2=A0=

=C2=A0 =C2=A0{

=C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "ht= tps://server.example.com",

=C2=A0 =C2=A0 =C2=A0=C2=A0"aud": "s6= BhdRkqt3",

=C2=A0 =C2=A0 =C2=A0=C2=A0"iat": 14715661= 54,

=C2=A0 =C2=A0 =C2=A0=C2=A0"jti": "bW= Jq=E2=80=9D,

=C2=A0 =C2=A0 =C2=A0=C2=A0=E2=80=9Ctarget=E2=80=9D:{<= /span>

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"sub": "24828976100= 1",

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"sid": &= quot;08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D

=C2=A0 =C2=A0 =C2=A0=C2=A0}

=C2=A0 =C2=A0 =C2=A0=C2=A0"events": {<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"http://schemas.= openid.net/event/backchannel-logout": {}

=C2=A0 =C2=A0 =C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0}

=C2=A0

The above formats address the following:=

=C2=A0

* Consistent structures

* Flexibility for profiles to target differently b= ut using a common attribute

* Multiple event types share a common target and m= ust be compatible (not sure if this is a plus or minus)

* No conflict around SET issuer vs subject issuer<= u>

* SET is substantially different such that existin= g access token and ID token code will reject consistently (because sub is m= issing)

* target could also have an attribute that indicat= es the target =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, IPa= ddress, and so on.

=C2=A0

Phil

=C2=A0

Oracle Corporation, Identity Cloud Services Archit= ect & Standards

@independentid

phil.hunt@oracle.com

=C2=A0


_______________________________________________
Id-event mailing list
Id-= event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-event

=C2=A0


--001a113718b25ef44c0552933214-- From nobody Thu Jun 22 14:40:31 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53476129484 for ; Thu, 22 Jun 2017 14:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3BIbqboH5Lv for ; Thu, 22 Jun 2017 14:40:26 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0452C1294AB for ; Thu, 22 Jun 2017 14:40:26 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id h134so22509856iof.2 for ; Thu, 22 Jun 2017 14:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UvWiaiLF6aSVfAzW6pVTHwRD1BRIwgJ3u2sxfw5gQDI=; b=nFhIrxvMCra7IWAGTIvJtJKDm9q1TjKKET0uGWDhMUYMLZJP9T1AKKsu+EV25/AHgl GF91H4fOfMuwz/M/IYCiA84DhylCWeR67DBrFwde5YNRMscfDyMeXLzY5iCzBXfSLEHz 98YWHYKfyAPKGPGO+W8X0tO3FT0jP/I8XWRhCfPyiwcXItp0nvaE197TMqgO4tAy1XIT 3MxoMKFyD69AATIoEzXavmdDkAfg8kX4Bs6MB25K5vspm6SaGjFX1yknhSHEBm3AJ/Cc T05GPtzaxmhg7l+SnvkYoHHvYmPTFCT0j+luk2PwYPPsT6nV0JhTBxCmCiKkW0xkU3O8 iZoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UvWiaiLF6aSVfAzW6pVTHwRD1BRIwgJ3u2sxfw5gQDI=; b=BEPtpXEoS/cvfYdOlvjcqucJA/2iRCzAVYwVSuJx+NrbTl+X3OKLV9oNZrdTFAxHNw CyAFIWnM1YDP1dnoPBK9nCYU7QGsMo+K6aNlLgcNM83DBbdmOHgAFQ4pBebA4FH45RpN ct2eAqdAKKlKVBoWpkBizguymv5Do/7p849lR0R7MOkqv+yl/ueN79GJQVxfqubL3aQz 386ExS8jObdgxvQ4lvGJ0UFvO6H1BrcXpJhxkAkNJ1sX/HC/lIaJPQa1Fxs7q1JQO7kv 6gRpYxEejRC3ozDNgjtHt1Z3JtJlPcTVeYOHa/Ts4+uV6kgolQbXallr2yxicc8CBv+r WrMA== X-Gm-Message-State: AKS2vOywFC2GV8h/LbwRgLrH309pq+5py3/eiv3rkGNVpsWk37rDnU5H P++zbayS8ilQ9KJyCzULztDrB4v5XkSd X-Received: by 10.107.36.3 with SMTP id k3mr4694355iok.130.1498167624978; Thu, 22 Jun 2017 14:40:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 22 Jun 2017 14:40:04 -0700 (PDT) In-Reply-To: References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> From: Marius Scurtescu Date: Thu, 22 Jun 2017 14:40:04 -0700 Message-ID: To: Andrew Nash Cc: Mike Jones , Phil Hunt , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a1140f9781a99cd0552935528" Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 21:40:30 -0000 --001a1140f9781a99cd0552935528 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2017 at 1:21 PM, Andrew Nash wrote: > Hey Folks, > > sorry to be inserted late - it appears that I have not been getting > updates from the mail server > The mail server sent me a message earlier that I have to reactivate my account because of bounces, not sure what's up with that. > > Looking over the 2 threads that appear to be related to this topic trying > to catch up it seems that a lot of issues have been juxtaposed > > it seems to me that continued use of the top level subject name is > reasonable as long as the SET/event level subject can be included as well > Yes, we could allow sub at both levels. Honestly not sure if that's a good idea, flexibility leads to complexity. Phil proposed to group all sub related attributes in one top level attribute for now called "target" (which would be at the same level as "events"). This brings sub higher up and gets rid of redundancy, but then all events in one SET must belong to the same profile (which maybe is a good thing). > --Andrew > > > > On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones > wrote: > >> It seems to me that most of the discussions motiving the proposals being >> made have been implicitly assuming that SETs are about digital identitie= s. >> In many of our use cases, they will be, which is great. I fully support >> structing events for identity profiles to meet the needs of those use >> cases, including often having a distinct SET issuer from the digital >> identity =E2=80=9Ciss=E2=80=9D value and having it and the digital ident= ity =E2=80=9Csub=E2=80=9D be in the >> event structure, when needed. >> >> >> >> But just like JWTs are great for digital identities (consider ID Tokens) >> but are used in completely unrelated ways as well (such as Caller-ID >> standards), SETs should be great for digital identities (consider RISC a= nd >> SCIM profiles) but also be great for unrelated use cases. >> >> >> >> In some use cases there will be only one =E2=80=9Ciss=E2=80=9D and the = =E2=80=9Csub=E2=80=9D may be very >> different from those we use for identities. We would be doing everyone = a >> disservice to many use cases if we tried to force that =E2=80=9Csub=E2= =80=9D and =E2=80=9Ciss=E2=80=9D be >> present at the event level, when those profiles don=E2=80=99t need it th= ere. >> >> >> >> We shouldn=E2=80=99t make every SET use more complicated syntax that onl= y more >> advanced use cases actually need. Therefore, we should leave the =E2=80= =9Csub=E2=80=9D and >> other claims descriptions as they are. Right now it=E2=80=99s general p= urpose and >> simple. Let=E2=80=99s not needlessly break that. >> >> >> >> -- Mike >> >> >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] * On Behalf Of *Phil >> Hunt >> *Sent:* Thursday, June 22, 2017 12:58 PM >> *To:* Marius Scurtescu >> *Cc:* ID Events Mailing List >> *Subject:* Re: [Id-event] Current vs. alternative subject exammples for >> SEC Token Draft >> >> >> >> Agreed to all your comments. And yes, =E2=80=9Ctarget=E2=80=9D is not t= he best name. >> Just can=E2=80=99t think of one at the moment. >> >> >> >> Thanks for the additional example. >> >> >> >> Phil >> >> >> >> Oracle Corporation, Identity Cloud Services Architect & Standards >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> On Jun 22, 2017, at 10:53 AM, Marius Scurtescu >> wrote: >> >> >> >> Thanks Phil, concrete examples are very useful. >> >> >> >> The top level "target" attribute is interesting, it reduces redundancy >> across events (when multiple events are present in one SET) but it is >> enforcing a single profile per SET. As you mention, not sure if this is >> good or bad. >> >> >> >> Also, not sure about the name of the attribute, "target", but I cannot >> come up with a better name. "target" sounds like "audience". We need >> something along with "events subject". Maybe simply nest the "iss", "sub= " >> and other right under "events"? >> >> >> >> Here is one more example of a SET not using "sub". SETs between an email >> provider and an implicit RP would use the OIDC defined "email" attribute >> (or "phone_number"): >> >> { >> >> "iss": "https://rp.example.com", >> >> "aud": "s6BhdRkqt3", >> >> "iat": 1471566154, >> >> "jti": "bWJq", >> >> "events": { >> >> "http://schemas.openid.net/event/risc//account-disabled": { >> >> "reason": "hijacking", >> >> "email": "bob@example.com", >> >> } >> >> } >> >> } >> >> >> >> >> >> >> >> >> >> >> Marius >> >> >> >> On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt wrote= : >> >> We=E2=80=99ve had a long standing thread on how to handle use of =E2=80= =9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D >> in SET. I=E2=80=99d like to give some examples that we can compare. >> >> >> >> Please add your comments. It would be good to reach some conclusion in >> the next few days if we are going to change the draft for Prague. >> >> >> >> Thanks! >> >> >> >> Three current draft examples: >> >> >> >> 1. A SCIM Event looks like: >> >> { >> >> "*jti*": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "*iat*": 1458496025, >> >> "*iss*": "https://security.example.com", >> >> "*aud*": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", >> >> "events": { >> >> "urn:ietf:params:scim:event:passwordReset": { } >> >> } >> >> } >> >> >> >> 2. An OP issued Backchannel Logout (single-sign-out) looks like: >> >> { >> >> "*iss*": "https://server.example.com", >> >> "sub": "248289761001", >> >> "*aud*": "s6BhdRkqt3", >> >> "*iat*": 1471566154, >> >> "*jti*": "bWJq", >> >> "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02", >> >> "events": { >> >> "http://schemas.openid.net/event/backchannel-logout": {} >> >> } >> >> } >> >> >> >> 3. An RP issued Application Logout Looks like (different issuer): >> >> { >> >> "*iss*": "https://rp.example.com", >> >> "*aud*": "s6BhdRkqt3", >> >> "*iat*": 1471566154, >> >> "*jti*": "bWJq", >> >> "events": { >> >> "http://schemas.openid.net/event/risc-logout": { >> >> "sub": "248289761001", >> >> "*iss*": "https://server.example.com=E2=80=9D, >> >> "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02" >> >> } >> >> } >> >> } >> >> >> >> I believe the concerns here are: >> >> >> >> - Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsist= ent and moves around. >> - SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use = its own >> attribute in the payload (introducing more variability). As long as = =E2=80=9Csub=E2=80=9D >> is valid to use in SET than profiling specs can redefine sub for thei= r own >> purposes. Is this good or bad? >> - Those writing parsers have to be concerned that when they are >> parsing a SET they need to know the role of the server OR they have t= o >> fully parse the entire object to determine if they are looking at str= ucture >> 2 or 3. IOW a lot of implementations have to always check for an emb= edded >> =E2=80=9Ciss=E2=80=9D to be sure they have the correct subject. >> - A concern about the trade-offs if multiple event types are >> expressed, should they share a common top-level attribute. How does t= his >> improve or complicate multi-type events? In the draft, note that Fig= ure 1 >> shows an event with a localized extension that adds value without imp= acting >> inter-op. >> - =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top= -level. We=E2=80=99ve >> been discussing that additional attributes should be in the payload. = Item 3 >> shows sid in the payload. Which is correct? >> >> >> >> =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D >> >> >> >> A. We could say that all SETs must embed sub and iss (if they use iss >> for identifying subjects) in the payload. See example 3 above. This wo= uld >> exclude options 1 and 2 and at least make it consistent that subject >> information is always in the payload. >> >> >> >> B. A new top-level attribute could be defined which is a JSON object. >> Inside the JSON object, profiling specs can define how their subjects ar= e >> addressed. Let=E2=80=99s call it target. A new common SET format might = look >> something like: >> >> >> >> { >> >> "*jti*": "3d0c3cf797584bd193bd0fb1bd4e7d30", >> >> "*iat*": 1458496025, >> >> "*iss*": "https://security.example.com", >> >> "*aud*": [ >> >> "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", >> >> "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" >> >> ], >> >> "target":{ >> >> "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", >> >> "*iss*": "https://scim.example.com" >> >> }, >> >> "events": { >> >> "urn:ietf:params:scim:event:passwordReset": { } >> >> } >> >> } >> >> >> >> Here is an example modified logout >> >> { >> >> "*iss*": "https://server.example.com", >> >> "*aud*": "s6BhdRkqt3", >> >> "*iat*": 1471566154, >> >> "*jti*": "bWJq=E2=80=9D, >> >> =E2=80=9Ctarget=E2=80=9D:{ >> >> "sub": "248289761001", >> >> "*sid*": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D >> >> } >> >> "events": { >> >> "http://schemas.openid.net/event/backchannel-logout": {} >> >> } >> >> } >> >> >> >> The above formats address the following: >> >> >> >> * Consistent structures >> >> * Flexibility for profiles to target differently but using a common >> attribute >> >> * Multiple event types share a common target and must be compatible (not >> sure if this is a plus or minus) >> >> * No conflict around SET issuer vs subject issuer >> >> * SET is substantially different such that existing access token and ID >> token code will reject consistently (because sub is missing) >> >> * target could also have an attribute that indicates the target =E2=80= =9Ctype=E2=80=9D >> such as SCIM resource, OP subject, IPaddress, and so on. >> >> >> >> Phil >> >> >> >> Oracle Corporation, Identity Cloud Services Architect & Standards >> >> @independentid >> >> www.independentid.com >> >> phil.hunt@oracle.com >> >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > --001a1140f9781a99cd0552935528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 1:21 PM, Andrew Nash <andrew@confyrm= .com> wrote:
Hey Folks,

sorry to be inserted late - it appears tha= t I have not been getting updates from the mail server

The mail server sent me a message earlier that I ha= ve to reactivate my account because of bounces, not sure what's up with= that.
=C2=A0

Looking over the 2 threads that appear to be related = to this topic trying to catch up it seems that a lot of issues have been ju= xtaposed=C2=A0

it seems to me that continued use o= f the top level subject name is reasonable as long as the SET/event level s= ubject can be included as well=C2=A0

Yes, we could allow sub at both levels. Honestly not sure if that'= ;s a good idea, flexibility leads to complexity.

P= hil proposed to group all sub related attributes in one top level attribute= for now called "target" (which would be at the same level as &qu= ot;events"). This brings sub higher up and gets rid of redundancy, but= then all events in one SET must belong to the same profile (which maybe is= a good thing).


--Andrew=C2=A0



On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

It seems to me that mo= st of the discussions motiving the proposals being made have been implicitl= y assuming that SETs are about digital identities.=C2=A0 In many of our use= cases, they will be, which is great.=C2=A0 I fully support structing events for identity profiles to meet the needs of = those use cases, including often having a distinct SET issuer from the digi= tal identity =E2=80=9Ciss=E2=80=9D value and having it and the digital iden= tity =E2=80=9Csub=E2=80=9D be in the event structure, when needed.

=C2=A0

But just like JWTs are= great for digital identities (consider ID Tokens) but are used in complete= ly unrelated ways as well (such as Caller-ID standards), SETs should be gre= at for digital identities (consider RISC and SCIM profiles) but also be great for unrelated use cases.<= u>

=C2=A0

In some use cases ther= e will be only one =E2=80=9Ciss=E2=80=9D and the =E2=80=9Csub=E2=80=9D may = be very different from those we use for identities.=C2=A0 We would be doing= everyone a disservice to many use cases if we tried to force that =E2=80= =9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D be present at the event level, when those profil= es don=E2=80=99t need it there.

=C2=A0

We shouldn=E2=80=99t m= ake every SET use more complicated syntax that only more advanced use cases= actually need.=C2=A0 Therefore, we should leave the =E2=80=9Csub=E2=80=9D = and other claims descriptions as they are.=C2=A0 Right now it=E2=80=99s gen= eral purpose and simple.=C2=A0 Let=E2=80=99s not needlessly break that.<= u>

=C2=A0

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

= =C2=A0

From: Id-event [mailto:id-event-bounces@ietf= .org] On Behalf Of Phil Hunt
Sent: Thursday, June 22, 2017 12:58 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Current vs. alternative subject exammples fo= r SEC Token Draft

=C2=A0

Agreed to all your comments.=C2=A0 And yes, =E2=80= =9Ctarget=E2=80=9D is not the best name.=C2=A0 Just can=E2=80=99t think of = one at the moment.

=C2=A0

Thanks for the additional example. =C2=A0<= /u>

=C2=A0

Phil

=C2=A0

Oracle Corporation, Iden= tity Cloud Services Architect & Standards

@independentid=

phil= .hunt@oracle.com

=C2=A0

On Jun 22, 2017, at 10:53 AM, Marius Scurtescu <<= a class=3D"cremed">mscurtescu@google.com> wrote:

=C2=A0

Thanks Phil, concrete examples are very useful.=

=C2=A0

The top level "target" attribute is inte= resting, it reduces redundancy across events (when multiple events are pres= ent in one SET) but it is enforcing a single profile per SET.=C2=A0 As you mention, not sure if this is good or bad.<= /span>

=C2=A0

Also, not sure about the name of the attribute, &q= uot;target", but I cannot come up with a better name. "target&quo= t; sounds like "audience". We need something along with "eve= nts subject". Maybe simply nest the "iss", "sub" and other right und= er "events"?

=C2=A0

Here is one more example of a SET not using "= sub". SETs between an email provider and an implicit RP would use the = OIDC defined "email" attribute (or "phone_number"):<= /u>

{

=C2=A0 =C2=A0"iss": "htt= ps://rp.example.com",

=C2=A0 =C2=A0"aud": "s6BhdRkqt3",

=C2=A0 =C2=A0"iat": 1471566154,

=C2=A0 =C2=A0"jti": "bWJq",=

=C2=A0 =C2=A0"events": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0"reason": "hijack= ing",

=C2=A0 =C2=A0 =C2=A0 =C2=A0"email": "bob@example.com",

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

}

=C2=A0

=C2=A0

=C2=A0

=C2=A0


Marius

=C2=A0

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt= =C2=A0<phil.hunt@oracle.com>=C2= =A0wrote:

We=E2=80=99ve had a long standing thread on how to= handle use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET.=C2= =A0 I=E2=80=99d like to give some examples that we can compare.

=C2=A0

Please add your comments. It would be good to reac= h some conclusion in the next few days if we are going to change the draft = for Prague.

=C2=A0

Thanks!

=C2=A0

Three current draft examples:=

=C2=A0

1. A SCIM Event looks like:

{=C2=A0

=C2=A0=C2=A0"jti": "3d0= c3cf797584bd193bd0fb1bd4e7d30",

=C2=A0=C2=A0"iat": 145849602= 5,

=C2=A0=C2=A0"iss": "https://security.example.com", =C2=A0=

=C2=A0=C2=A0"aud": [<= u>

=C2=A0=C2=A0], =C2=A0

=C2=A0=C2=A0"events": {

=C2=A0 =C2=A0=C2=A0"urn:ietf:params:scim= :event:passwordReset": { }

=C2=A0=C2=A0}

}

=C2=A0

2. An OP issued Backchannel Logout (single-sign-ou= t) looks like:

=C2=A0 =C2=A0{

=C2=A0 =C2=A0 =C2=A0=C2=A0"sub": &q= uot;248289761001",

=C2=A0 =C2=A0 =C2=A0=C2=A0"aud&qu= ot;: "s6BhdRkqt3",

=C2=A0 =C2=A0 =C2=A0=C2=A0"iat&qu= ot;: 1471566154,

=C2=A0 =C2=A0 =C2=A0=C2=A0"jti&qu= ot;: "bWJq",

=C2=A0 =C2=A0 =C2=A0=C2=A0"sid&qu= ot;: "08a5019c-17e1-4977-8f42-65a12843ea02",

=C2=A0 =C2=A0 =C2=A0=C2=A0"events":= {

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"http://schemas.openid.net/event/backchannel-logout&q= uot;: {}

=C2=A0 =C2=A0 =C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0}

=C2=A0

3. An RP issued Application Logout Looks like (dif= ferent issuer):

{

=C2=A0=C2=A0=C2=A0"iss": &qu= ot;https://rp.example.com",

=C2=A0=C2=A0=C2=A0"aud": &qu= ot;s6BhdRkqt3",

=C2=A0=C2=A0=C2=A0"iat": 147= 1566154,

=C2=A0=C2=A0=C2=A0"jti": &qu= ot;bWJq",

=C2=A0=C2=A0=C2=A0"events": {

=C2=A0=C2=A0 =C2=A0=C2=A0"http://schemas.openid.net/event/risc-logout": {

=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0"sub&quo= t;: "248289761001",

=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0"iss<= /u>": "https://server.example.com=E2=80= =9D,

=C2=A0 =C2=A0 =C2=A0 =C2=A0"sid": "0= 8a5019c-17e1-4977-8f42-65a12843ea02"

=C2=A0=C2=A0 =C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0}

}

=C2=A0

I believe the concerns here are:

=C2=A0

  • Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent an= d moves around. =C2=A0
  • SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its ow= n attribute in the payload (introducing more variability).=C2=A0 As long as= =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can rede= fine sub for their own purposes.=C2=A0 Is this good or bad?
  • Those writing parsers have to be concerned that when they are parsing a S= ET they need to know the role of the server OR they have to fully parse the= entire object to determine if they are looking at structure 2 or 3.=C2=A0 IOW a lot of implementations have to always che= ck for an embedded =E2=80=9Ciss=E2=80=9D to be sure they have the correct s= ubject.
  • A concern about the trade-offs if multiple event types are expressed, sho= uld they share a common top-level attribute. How does this improve or compl= icate multi-type events?=C2=A0 In the draft, note that Figure 1 shows an event with a localized extension that adds value wi= thout impacting inter-op.
  • =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the top-level= . We=E2=80=99ve been discussing that additional attributes should be in the= payload. Item 3 shows sid in the payload. Which is correct?<= /span>

=C2=A0

=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D= =3D=3D=3D

=C2=A0

A.=C2=A0 We could say that all SETs must embed sub= and iss (if they use iss for identifying subjects) in the payload.=C2=A0 S= ee example 3 above.=C2=A0 This would exclude options 1 and 2 and at least make it consistent that subject information is always in the = payload. =C2=A0

=C2=A0

B. A new top-level attribute could be defined whic= h is a JSON object. Inside the JSON object, profiling specs can define how = their subjects are addressed. Let=E2=80=99s call it target.=C2=A0 A new common SET format might look something like:

=C2=A0

{=C2=A0

=C2=A0=C2=A0"jti": "3d0= c3cf797584bd193bd0fb1bd4e7d30",

=C2=A0=C2=A0"iat": 145849602= 5,

=C2=A0=C2=A0"iss": "https://security.example.com", =C2=A0=

=C2=A0=C2=A0"aud": [<= u>

=C2=A0=C2=A0], =C2=A0

=C2=A0=C2=A0"target":{=

=C2=A0 =C2=A0=C2=A0"iss= ": "https://scim.example.com"

=C2=A0=C2=A0},

=C2=A0=C2=A0"events": {

=C2=A0 =C2=A0=C2=A0"urn:ietf:params:scim= :event:passwordReset": { }

=C2=A0=C2=A0}

}

=C2=A0

Here is an example modified logout=C2=A0=

=C2=A0 =C2=A0{

=C2=A0 =C2=A0 =C2=A0=C2=A0"iss": "https://server.example.com",

=C2=A0 =C2=A0 =C2=A0=C2=A0"aud": "s6= BhdRkqt3",

=C2=A0 =C2=A0 =C2=A0=C2=A0"iat": 14715661= 54,

=C2=A0 =C2=A0 =C2=A0=C2=A0"jti": "bW= Jq=E2=80=9D,

=C2=A0 =C2=A0 =C2=A0=C2=A0=E2=80=9Ctarget=E2= =80=9D:{

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"sub&qu= ot;: "248289761001",

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"sid": &= quot;08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D

=C2=A0 =C2=A0 =C2=A0=C2=A0}

=C2=A0 =C2=A0 =C2=A0=C2=A0"events": {<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"http://schemas.openid.net/event/backchannel-logout": {}

=C2=A0 =C2=A0 =C2=A0=C2=A0}

=C2=A0=C2=A0=C2=A0}

=C2=A0

The above formats address the following:=

=C2=A0

* Consistent structures

* Flexibility for profiles to target differently b= ut using a common attribute

* Multiple event types share a common target and m= ust be compatible (not sure if this is a plus or minus)

* No conflict around SET issuer vs subject issuer<= u>

* SET is substantially different such that existin= g access token and ID token code will reject consistently (because sub is m= issing)

* target could also have an attribute that indicat= es the target =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, IPa= ddress, and so on.

=C2=A0

Phil

=C2=A0

Oracle Corporation, Identity Cloud Services Archit= ect & Standards

@independentid

phil.hunt@oracle.com

=C2=A0


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=

=C2=A0


_______________________________________________
Id-event mailing list
Id-= event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



--001a1140f9781a99cd0552935528-- From nobody Thu Jun 22 14:43:11 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F1129B82 for ; Thu, 22 Jun 2017 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj6uJMyN5t8g for ; Thu, 22 Jun 2017 14:43:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D1129B81 for ; Thu, 22 Jun 2017 14:43:06 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5MLh2sb002848 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 21:43:03 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5MLh2mu016562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jun 2017 21:43:02 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5MLh1hL024070; Thu, 22 Jun 2017 21:43:02 GMT Received: from dhcp-whq-twvpn-3-vpnpool-10-159-243-142.vpn.oracle.com (/10.159.243.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Jun 2017 14:43:01 -0700 From: Phil Hunt Message-Id: <0FC0B88A-891A-41E9-A770-6F85C07C87B1@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_01948F2F-C439-490E-845E-B74B32CF5F1F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 22 Jun 2017 14:42:59 -0700 In-Reply-To: Cc: Andrew Nash , Mike Jones , ID Events Mailing List To: Marius Scurtescu References: <4AC644C3-4AF5-4059-9AC6-D90072FE09F1@oracle.com> <5538EF8A-ADFF-4EB4-96DC-6932058627C5@oracle.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Current vs. alternative subject exammples for SEC Token Draft X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 21:43:11 -0000 --Apple-Mail=_01948F2F-C439-490E-845E-B74B32CF5F1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve been noticing a number of people are bouncing particularly = on Google domains. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 22, 2017, at 2:40 PM, Marius Scurtescu = wrote: >=20 > On Thu, Jun 22, 2017 at 1:21 PM, Andrew Nash > wrote: > Hey Folks, >=20 > sorry to be inserted late - it appears that I have not been getting = updates from the mail server >=20 > The mail server sent me a message earlier that I have to reactivate my = account because of bounces, not sure what's up with that. > =20 >=20 > Looking over the 2 threads that appear to be related to this topic = trying to catch up it seems that a lot of issues have been juxtaposed=20 >=20 > it seems to me that continued use of the top level subject name is = reasonable as long as the SET/event level subject can be included as = well=20 >=20 > Yes, we could allow sub at both levels. Honestly not sure if that's a = good idea, flexibility leads to complexity. >=20 > Phil proposed to group all sub related attributes in one top level = attribute for now called "target" (which would be at the same level as = "events"). This brings sub higher up and gets rid of redundancy, but = then all events in one SET must belong to the same profile (which maybe = is a good thing). >=20 >=20 > --Andrew=20 >=20 >=20 >=20 > On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones = > = wrote: > It seems to me that most of the discussions motiving the proposals = being made have been implicitly assuming that SETs are about digital = identities. In many of our use cases, they will be, which is great. I = fully support structing events for identity profiles to meet the needs = of those use cases, including often having a distinct SET issuer from = the digital identity =E2=80=9Ciss=E2=80=9D value and having it and the = digital identity =E2=80=9Csub=E2=80=9D be in the event structure, when = needed. >=20 > =20 >=20 > But just like JWTs are great for digital identities (consider ID = Tokens) but are used in completely unrelated ways as well (such as = Caller-ID standards), SETs should be great for digital identities = (consider RISC and SCIM profiles) but also be great for unrelated use = cases. >=20 > =20 >=20 > In some use cases there will be only one =E2=80=9Ciss=E2=80=9D and the = =E2=80=9Csub=E2=80=9D may be very different from those we use for = identities. We would be doing everyone a disservice to many use cases = if we tried to force that =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D = be present at the event level, when those profiles don=E2=80=99t need it = there. >=20 > =20 >=20 > We shouldn=E2=80=99t make every SET use more complicated syntax that = only more advanced use cases actually need. Therefore, we should leave = the =E2=80=9Csub=E2=80=9D and other claims descriptions as they are. = Right now it=E2=80=99s general purpose and simple. Let=E2=80=99s not = needlessly break that. >=20 > =20 >=20 > -- Mike >=20 > =C2=A0 <> > From: Id-event [mailto:id-event-bounces@ietf = .org] On Behalf Of Phil Hunt > Sent: Thursday, June 22, 2017 12:58 PM > To: Marius Scurtescu > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] Current vs. alternative subject exammples for = SEC Token Draft >=20 > =20 >=20 > Agreed to all your comments. And yes, =E2=80=9Ctarget=E2=80=9D is not = the best name. Just can=E2=80=99t think of one at the moment. >=20 > =20 >=20 > Thanks for the additional example. =20 >=20 > =20 >=20 > Phil >=20 > =20 >=20 > Oracle Corporation, Identity Cloud Services Architect & Standards >=20 > @independentid >=20 > www.independentid.com <> > phil.hunt@oracle.com <> > =20 >=20 > On Jun 22, 2017, at 10:53 AM, Marius Scurtescu > wrote: >=20 > =20 >=20 > Thanks Phil, concrete examples are very useful. >=20 > =20 >=20 > The top level "target" attribute is interesting, it reduces redundancy = across events (when multiple events are present in one SET) but it is = enforcing a single profile per SET. As you mention, not sure if this is = good or bad. >=20 > =20 >=20 > Also, not sure about the name of the attribute, "target", but I cannot = come up with a better name. "target" sounds like "audience". We need = something along with "events subject". Maybe simply nest the "iss", = "sub" and other right under "events"? >=20 > =20 >=20 > Here is one more example of a SET not using "sub". SETs between an = email provider and an implicit RP would use the OIDC defined "email" = attribute (or "phone_number"): >=20 > { >=20 > "iss": "https://rp.example.com <>", >=20 > "aud": "s6BhdRkqt3", >=20 > "iat": 1471566154, >=20 > "jti": "bWJq", >=20 > "events": { >=20 > "http://schemas.openid.net/event/risc//account-disabled <>": { >=20 > "reason": "hijacking", >=20 > "email": "bob@example.com <>", >=20 > } >=20 > } >=20 > } >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 > Marius >=20 > =20 >=20 > On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt > = wrote: >=20 > We=E2=80=99ve had a long standing thread on how to handle use of = =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET. I=E2=80=99d = like to give some examples that we can compare. >=20 > =20 >=20 > Please add your comments. It would be good to reach some conclusion in = the next few days if we are going to change the draft for Prague. >=20 > =20 >=20 > Thanks! >=20 > =20 >=20 > Three current draft examples: >=20 > =20 >=20 > 1. A SCIM Event looks like: >=20 > {=20 >=20 > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >=20 > "iat": 1458496025, >=20 > "iss": "https://security.example.com <>", =20 >=20 > "aud": [ >=20 > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <>", >=20 > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <>" >=20 > ], =20 >=20 > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = <>", >=20 > "events": { >=20 > "urn:ietf:params:scim:event:passwordReset": { } >=20 > } >=20 > } >=20 > =20 >=20 > 2. An OP issued Backchannel Logout (single-sign-out) looks like: >=20 > { >=20 > "iss": "https://server.example.com <>", >=20 > "sub": "248289761001", >=20 > "aud": "s6BhdRkqt3", >=20 > "iat": 1471566154, >=20 > "jti": "bWJq", >=20 > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02", >=20 > "events": { >=20 > "http://schemas.openid.net/event/backchannel-logout <>": {} >=20 > } >=20 > } >=20 > =20 >=20 > 3. An RP issued Application Logout Looks like (different issuer): >=20 > { >=20 > "iss": "https://rp.example.com <>", >=20 > "aud": "s6BhdRkqt3", >=20 > "iat": 1471566154, >=20 > "jti": "bWJq", >=20 > "events": { >=20 > "http://schemas.openid.net/event/risc-logout <>": { >=20 > "sub": "248289761001", >=20 > "iss": "https://server.example.com <>=E2=80=9D, >=20 > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02" >=20 > } >=20 > } >=20 > } >=20 > =20 >=20 > I believe the concerns here are: >=20 > =20 >=20 > Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is inconsistent = and moves around. =20 > SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it could use its = own attribute in the payload (introducing more variability). As long as = =E2=80=9Csub=E2=80=9D is valid to use in SET than profiling specs can = redefine sub for their own purposes. Is this good or bad? > Those writing parsers have to be concerned that when they are parsing = a SET they need to know the role of the server OR they have to fully = parse the entire object to determine if they are looking at structure 2 = or 3. IOW a lot of implementations have to always check for an embedded = =E2=80=9Ciss=E2=80=9D to be sure they have the correct subject. > A concern about the trade-offs if multiple event types are expressed, = should they share a common top-level attribute. How does this improve or = complicate multi-type events? In the draft, note that Figure 1 shows an = event with a localized extension that adds value without impacting = inter-op. > =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in the = top-level. We=E2=80=99ve been discussing that additional attributes = should be in the payload. Item 3 shows sid in the payload. Which is = correct? > =20 >=20 > =3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D >=20 > =20 >=20 > A. We could say that all SETs must embed sub and iss (if they use iss = for identifying subjects) in the payload. See example 3 above. This = would exclude options 1 and 2 and at least make it consistent that = subject information is always in the payload. =20 >=20 > =20 >=20 > B. A new top-level attribute could be defined which is a JSON object. = Inside the JSON object, profiling specs can define how their subjects = are addressed. Let=E2=80=99s call it target. A new common SET format = might look something like: >=20 > =20 >=20 > {=20 >=20 > "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", >=20 > "iat": 1458496025, >=20 > "iss": "https://security.example.com <>", =20 >=20 > "aud": [ >=20 > "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <>", >=20 > "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <>" >=20 > ], =20 >=20 > "target":{ >=20 > "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 = <>", >=20 > "iss": "https://scim.example.com <>" >=20 > }, >=20 > "events": { >=20 > "urn:ietf:params:scim:event:passwordReset": { } >=20 > } >=20 > } >=20 > =20 >=20 > Here is an example modified logout=20 >=20 > { >=20 > "iss": "https://server.example.com <>", >=20 > "aud": "s6BhdRkqt3", >=20 > "iat": 1471566154, >=20 > "jti": "bWJq=E2=80=9D, >=20 > =E2=80=9Ctarget=E2=80=9D:{ >=20 > "sub": "248289761001", >=20 > "sid": "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D >=20 > } >=20 > "events": { >=20 > "http://schemas.openid.net/event/backchannel-logout <>": {} >=20 > } >=20 > } >=20 > =20 >=20 > The above formats address the following: >=20 > =20 >=20 > * Consistent structures >=20 > * Flexibility for profiles to target differently but using a common = attribute >=20 > * Multiple event types share a common target and must be compatible = (not sure if this is a plus or minus) >=20 > * No conflict around SET issuer vs subject issuer >=20 > * SET is substantially different such that existing access token and = ID token code will reject consistently (because sub is missing) >=20 > * target could also have an attribute that indicates the target = =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, IPaddress, and = so on. >=20 > =20 >=20 > Phil >=20 > =20 >=20 > Oracle Corporation, Identity Cloud Services Architect & Standards >=20 > @independentid >=20 > www.independentid.com <> > phil.hunt@oracle.com <> > =20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org <> > https://www.ietf.org/mailman/listinfo/id-event <> > =20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/ = listinfo/i= d-event >=20 >=20 >=20 --Apple-Mail=_01948F2F-C439-490E-845E-B74B32CF5F1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve been noticing a number of people are bouncing = particularly on Google domains.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 22, 2017, at 2:40 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Thu, = Jun 22, 2017 at 1:21 PM, Andrew Nash <andrew@confyrm.com> wrote:
Hey Folks,

sorry to be inserted late - it appears that I have not been = getting updates from the mail server

The mail server sent me = a message earlier that I have to reactivate my account because of = bounces, not sure what's up with that.
 

Looking = over the 2 threads that appear to be related to this topic trying to = catch up it seems that a lot of issues have been = juxtaposed 

it seems to me that continued use of the top level subject = name is reasonable as long as the SET/event level subject can be = included as well 

Yes, we could allow sub at both levels. = Honestly not sure if that's a good idea, flexibility leads to = complexity.

Phil= proposed to group all sub related attributes in one top level attribute = for now called "target" (which would be at the same level as "events"). = This brings sub higher up and gets rid of redundancy, but then all = events in one SET must belong to the same profile (which maybe is a good = thing).


--Andrew 



On Thu, Jun 22, 2017 at 12:45 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

It seems to = me that most of the discussions motiving the proposals being made have = been implicitly assuming that SETs are about digital identities.  = In many of our use cases, they will be, which is great.  I fully support structing events for identity profiles to meet the needs = of those use cases, including often having a distinct SET issuer from = the digital identity =E2=80=9Ciss=E2=80=9D value and having it and the = digital identity =E2=80=9Csub=E2=80=9D be in the event structure, when = needed.

 

But just = like JWTs are great for digital identities (consider ID Tokens) but are = used in completely unrelated ways as well (such as Caller-ID standards), = SETs should be great for digital identities (consider RISC and SCIM profiles) but also be great for unrelated use cases.

 

In some use cases there will be only = one =E2=80=9Ciss=E2=80=9D and the =E2=80=9Csub=E2=80=9D may be very = different from those we use for identities.  We would be doing = everyone a disservice to many use cases if we tried to force that = =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D be present at the event level, when those = profiles don=E2=80=99t need it there.

 

We shouldn=E2=80=99t make every SET = use more complicated syntax that only more advanced use cases actually = need.  Therefore, we should leave the =E2=80=9Csub=E2=80=9D and = other claims descriptions as they are.  Right now it=E2=80=99s = general purpose and simple.  Let=E2=80=99s not needlessly break that.

 

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

 

From: = Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 22, 2017 12:58 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Current vs. alternative = subject exammples for SEC Token Draft

 

Agreed to all your = comments.  And yes, =E2=80=9Ctarget=E2=80=9D is not the best = name.  Just can=E2=80=99t think of one at the moment.

 

Thanks for the additional = example.  

 

Phil

 

Oracle = Corporation, Identity Cloud Services Architect & Standards

@independentid

www.independentid.com

phil.hunt@oracle.com

 

On Jun 22, 2017, at 10:53 AM, = Marius Scurtescu <mscurtescu@google.com> = wrote:

 

Thanks Phil, concrete examples are very useful.

 

The top level "target" attribute is interesting, it reduces = redundancy across events (when multiple events are present in one SET) = but it is enforcing a single profile per SET.  As you mention, not sure if this is good or bad.

 

Also, not sure about the name of the attribute, "target", but = I cannot come up with a better name. "target" sounds like "audience". We = need something along with "events subject". Maybe simply nest the "iss", "sub" and other right under "events"?

 

Here is one more example of a SET not using "sub". SETs = between an email provider and an implicit RP would use the OIDC defined = "email" attribute (or "phone_number"):

{

   "iss": "https://rp.example.com",

   "aud": "s6BhdRkqt3",

   "iat": 1471566154,

   "jti": "bWJq",

   "events": {

     "http://schemas.openid.net/event/risc//account-disabled": {

       "reason": "hijacking",

       "email": "bob@example.com",

     }

   }

}

 

 

 

 


Marius

 

On Thu, Jun 22, 2017 at 10:05 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

We=E2=80=99ve had a long standing thread on how to handle use = of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D in SET.  I=E2=80=99= d like to give some examples that we can compare.

 

Please add your comments. It would be good to reach some = conclusion in the next few days if we are going to change the draft for = Prague.

 

Thanks!

 

Three current draft examples:

 

1. A SCIM Event looks like:

{ 

  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",

  "iat": 1458496025,

  "iss": "https://security.example.com", =  

  "aud": [

    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",

    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"

  ],  

  "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",

  "events": {

    "urn:ietf:params:scim:event:passwordReset": = { }

  }

}

 

2. An OP issued Backchannel Logout (single-sign-out) looks = like:

   {

      "iss": "https://server.example.com",

      "sub": "248289761001",

      "aud": "s6BhdRkqt3",

      "iat": 1471566154,

      "jti": "bWJq",

      "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02",

      "events": {

        "http://schemas.openid.net/event/backchannel-logout": {}

      }

   }

 

3. An RP issued Application Logout Looks like (different = issuer):

{

   "iss": "https://rp.example.com",

   "aud": "s6BhdRkqt3",

   "iat": 1471566154,

   "jti": "bWJq",

   "events": {

     "http://schemas.openid.net/event/risc-logout": {

       "sub": "248289761001",

       "iss": "https://server.example.com=E2=80=9D,

       "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02"

     }

   }

}

 

I believe the concerns here are:

 

  • Use of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D is = inconsistent and moves around.  
  • SCIM could redefine =E2=80=9Csub=E2=80=9D as a URI or it = could use its own attribute in the payload (introducing more = variability).  As long as =E2=80=9Csub=E2=80=9D is valid to use in = SET than profiling specs can redefine sub for their own purposes.  Is this good or bad?
  • Those writing parsers have to be concerned that when they are = parsing a SET they need to know the role of the server OR they have to = fully parse the entire object to determine if they are looking at structure 2 or 3.  IOW a lot of implementations have to always = check for an embedded =E2=80=9Ciss=E2=80=9D to be sure they have the = correct subject.
  • A concern about the trade-offs if multiple event types are = expressed, should they share a common top-level attribute. How does this = improve or complicate multi-type events?  In the draft, note that Figure 1 shows an event with a localized extension that adds value = without impacting inter-op.
  • =E2=80=9Csid=E2=80=9D in Figure 2 of the SET document is in = the top-level. We=E2=80=99ve been discussing that additional attributes = should be in the payload. Item 3 shows sid in the payload. Which is = correct?

 

=3D=3D=3D=3D=3D=3D=3DPossible Options=3D=3D=3D=3D=3D=3D=3D

 

A.  We could say that all SETs must embed sub and iss = (if they use iss for identifying subjects) in the payload.  See = example 3 above.  This would exclude options 1 and 2 and at least make it consistent that subject information is always in = the payload.  

 

B. A new top-level attribute could be defined which is a JSON = object. Inside the JSON object, profiling specs can define how their = subjects are addressed. Let=E2=80=99s call it target.  A new common SET format might look something like:

 

{ 

  "jti": = "3d0c3cf797584bd193bd0fb1bd4e7d30",

  "iat": 1458496025,

  "iss": "https://security.example.com", =  

  "aud": [

    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",

    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"

  ],  

  "target":{

    "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",

    "iss": "https://scim.example.com"

  },

  "events": {

    "urn:ietf:params:scim:event:passwordReset": = { }

  }

}

 

Here is an example modified logout 

   {

      "iss": "https://server.example.com",

      "aud": = "s6BhdRkqt3",

      "iat": = 1471566154,

      "jti": = "bWJq=E2=80=9D,

      =E2=80=9Ctarget=E2=80=9D:{

        "sub": "248289761001",

        "sid": = "08a5019c-17e1-4977-8f42-65a12843ea02=E2=80=9D

      }

      "events": {

        "http://schemas.openid.net/event/backchannel-logout": {}

      }

   }

 

The above formats address the following:

 

* Consistent structures

* Flexibility for profiles to target differently but using a = common attribute

* Multiple event types share a common target and must be = compatible (not sure if this is a plus or minus)

* No conflict around SET issuer vs subject issuer

* SET is substantially different such that existing access = token and ID token code will reject consistently (because sub is = missing)

* target could also have an attribute that indicates the = target =E2=80=9Ctype=E2=80=9D such as SCIM resource, OP subject, = IPaddress, and so on.

 

Phil

 

Oracle Corporation, Identity Cloud Services Architect & = Standards

@independentid

www.independentid.com

phil.hunt@oracle.com

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




= --Apple-Mail=_01948F2F-C439-490E-845E-B74B32CF5F1F-- From nobody Fri Jun 23 17:09:54 2017 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE28129B35; Fri, 23 Jun 2017 17:07:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282249.7840.9484400381264146108.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:02 -0700 Archived-At: Subject: [Id-event] secevent - Requested session has been scheduled for IETF 99 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:03 -0000 Dear Yaron Sheffer, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secevent Session 1 (2:00:00) Tuesday, Morning Session I 0930-1200 Room Name: Karlin I/II size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Security Events Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag jsonbis httpbis dispatch oauth tokbind tls acme Second Priority: ipsecme sacm ace People who must be present: Yaron Sheffer Kathleen Moriarty Dick Hardt Resources Requested: Special Requests: Please avoid cfrg. --------------------------------------------------------- From nobody Sun Jun 25 07:31:47 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0415A127342 for ; Sun, 25 Jun 2017 07:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs21XxG75wyQ for ; Sun, 25 Jun 2017 07:31:40 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152DE127077 for ; Sun, 25 Jun 2017 07:31:39 -0700 (PDT) X-AuditID: 1209190f-495ff700000002a7-5d-594fc9497e5e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F2.1D.00679.949CF495; Sun, 25 Jun 2017 10:31:38 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v5PEVZ9R024545; Sun, 25 Jun 2017 10:31:35 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5PEVVJh022197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 25 Jun 2017 10:31:32 -0400 To: Mike Jones , Phil Hunt , "Richard Backman, Annabelle" Cc: Marius Scurtescu , John Bradley , Henk Birkholz , Yaron Sheffer , ID Events Mailing List References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> From: Justin Richer Message-ID: <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> Date: Sun, 25 Jun 2017 10:31:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------23AD7323520B4A5B083042E7" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsUixCmqret10j/SoH2LlkXDv7+sFh0Lupks 9k77xGJx6+waJosF8xvZLdofc1isvvuXzWLV/RnsDhweKy50sXrsnHWX3WPBplKPJUt+Mnm0 7vjL7vHx6S0Wj44HNxg9bt/eyBLAEcVlk5Kak1mWWqRvl8CV8XqObsHvH2IVTxZ1sDUwTt/M 3sXIySEhYCJxc/ty1i5GLg4hgcVMEj8v7YNyNjJKPNi0gB3Cuc0k8fntF0aQFmGBCIn/2/pY QBIiAtMYJU7N3QbmMAv8YJS4c/oNG0iVkEAbh8TsrSkgNpuAqsT0NS1MIDavgJXEqqc7wCax AMU3ffgJFhcViJG4NvMOK0SNoMTJmU+AhnJwcArEStzsdgIxmQXCJBacUQGpYBYQl7j1ZD7T BEaBWUgaZiFUzUJSBWHbStyZu5sZwpaXaN46G8rWlVi0bQU7svgCRvZVjLIpuVW6uYmZOcWp ybrFyYl5ealFuiZ6uZkleqkppZsYwfEnyb+DcU6D9yFGAQ5GJR7egLV+kUKsiWXFlbmHGCU5 mJREeRv9/SOF+JLyUyozEosz4otKc1KLDzFKcDArifAGZgDleFMSK6tSi/JhUtIcLErivOIa jRFCAumJJanZqakFqUUwWRkODiUJ3vDjQI2CRanpqRVpmTklCGkmDk6Q4TxAw2WOgQwvLkjM Lc5Mh8ifYlSUEudtPgGUEABJZJTmwfWC0mPC28OmrxjFgV4R5l0NsoIHmFrhul8BDWYCGjxj jQ/I4JJEhJRUA2Ozhza719K6SVL3tZRZuK8mGy32fCwb/E52gWOE2W61DLOEX/PfX71zJ15X Nqv6WV7AtBe2GxKm5XC81g44Iz//iVuyfUiyWOJXl8cqMWGsQTpKmx1NGE84fVGMTv+m6WoT 3Bv+6PPRb/c2JAbMOB0W+2RJ52anb38vXLukve2wrh1n6dZ315RYijMSDbWYi4oTAVu7V0Nq AwAA Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 14:31:46 -0000 This is a multi-part message in MIME format. --------------23AD7323520B4A5B083042E7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Mike, this is not at all what I see for having the "most support". Instead I'm seeing a lot of call for having "sub" defined clearly in the event payload only. The "sub" of the main body is the subject as known by the issuer of the SET itself. This might be the same subject that the subject is known by at the target of the SET. There are many cases where this isn't true, and so far one exception case where it is, sometimes. We should not be writing this for the exception. But I think there's a pretty clear path forward. The "sub" in the body of a SET, if it is included, is *ALWAYS* in the context of the "iss" of the SET. Always, full stop, no exceptions. No global namespaces, no restrictions on content, no formats -- it's an opaque (to the SET standard) value in the domain of the issuer of the SET. Event payloads, defined in profiles, describe a subject of the event itself. Importantly, this is the subject as known by the context in which the event will be *received*, not in which it was *issued*. Sometimes those are the same, more often (as we're seeing) we can't guarantee that. We should not depend on that and we should not treat the exceptional case as the usual, no matter what syntax another group has come up with. So here's the thing. I think the "sub" of an event should be optional, and ALWAYS in the context of the issuer, and profiles should not places further constraints on that. Events themselves should be self-contained. I regret that we didn't make the registration object in RFC7591 more self-contained, as that's caused implementation and extension issues. I think events should always have an internal subject/issuer pair, in the context of where the event is being consumed. We need to define what iss/sub mean (in a grand sense) inside the event object in this document, so that different events don't reinvent the same thing over and over. If a profile wants to leave that out because they don't need an identifier for the payload, then they can leave it out. If they want to leave it out because they want to assume there will "always" be an iss/sub in the root of the SET, then I have a problem with that. The issuer of the SET can, and probably does, have its own identifier which can't be assumed to be universal. Proposing a global subject namespace or format, as has been suggested elsewhere on this list, is ludicrous and will never fly as it goes against how JWT namespacing for people and objects has always worked. We should have a clear semantic data structure that can be extended and used by all of the use cases that we've adopted. Optimizing at this stage, especially based on one event, is going to just lead to things being broken and back-patched later on. But if one spec wants to leave out the iss/sub inside the event? They can still do that, but I think that's pretty daft. In summary: * iss: issuer of the event * sub: subject of the event as known by the issuer of the event * event.sub: subject of the event as known by the recipient of the event * event.iss: context for the subject of the event as known by the recipient of the event * event.aud: recipient of the event -- Justin On 6/21/2017 7:45 PM, Mike Jones wrote: > > The proposal that I believe has the most support is keeping things as > they are, leaving it up to profiles and applications to define which > claims they use and how they use them. > > It would be fine for some profiles to use the language below. > > Mike > > *From: *Phil Hunt > *Sent: *Wednesday, June 21, 2017 6:39 PM > *To: *Richard Backman, Annabelle > *Cc: *Marius Scurtescu ; John Bradley > ; Henk Birkholz > ; Justin Richer > ; Yaron Sheffer > ; Mike Jones > ; ID Events Mailing List > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > So I understand what is being proposed is: > > If the event type uses sub to identify its subject, and the issuer > of the subject is identical to the issuer for the event, then sub > may be used at the top level. Otherwise, the subject of an event (e.g. > sub) and any other claims required to uniquely identify the subject > MUST be contained in the event payload. > > For example, an ip address of 1.2.3.4 might be represented in a > ipaddress claim defined in the event payload. ipaddress:1.2.3.4" > A SCIM resource URI of > https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might > be identified in the event payload as: > sub:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 > > A Connect Logout event from an OP uses the top level sub claim and > depends on iss being the same for the event issuer AND the subject. > This means that no party may issue logout events on behalf of the OP. > > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle >> > wrote: >> >> Fair point. If we do not intend to support multiple profiles within a >> single SET, then Im less concerned about leaving sub semantics up to >> the profiles. >> -- >> Annabelle Richard Backman >> Identity Services >> *From:*Marius Scurtescu > > >> *Date:*Wednesday, June 21, 2017 at 2:58 PM >> *To:*"Richard Backman, Annabelle" > > >> *Cc:*"Phil Hunt (IDM)" > >, John Bradley > >, Henk Birkholz >> > >, Justin Richer >> >, Yaron Sheffer >> >, Michael Jones >> >, >> ID Events Mailing List > >> *Subject:*Re: [Id-event] solution for Id/Access Token confusion and >> distinct SET issuer >> Example for multiple events within same profile: IdP account is >> disabled (because of hijacking), this can lead to two events: >> 1. "account-disabled" >> 2. "sessions-revoked" >> >> Marius >> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle >> > wrote: >>> The spec says that the events claim SHOULD NOT be used to express >>> multiple logical events. If its also not used to express events >>> from different profiles that correspond to the same logical event >>> (e.g. an OIDC backchannel logout event alongside a hypothetical RISC >>> logout event), then Im not sure what use case that leaves for >>> multiple events in one SET. >>> -- >>> Annabelle Richard Backman >>> Identity Services >>> *From:*Id-event >> > on behalf of "Phil Hunt (IDM)" >>> > >>> *Date:*Wednesday, June 21, 2017 at 2:12 PM >>> *To:*John Bradley > >>> *Cc:*"Richard Backman, Annabelle" >> >, Henk Birkholz >>> >> >, Justin Richer >>> >, Marius Scurtescu >>> >, Yaron >>> Sheffer >, >>> Michael Jones >> >, ID Events Mailing List >>> > >>> >>> *Subject:*Re: [Id-event] solution for Id/Access Token confusion and >>> distinct SET issuer >>> Separate or combined may be evolving. Mike wants to keep the current >>> backchannel logout very narrowly scoped. He suggested risc define >>> its own duplicate definitions and meanings. >>> That leads me to believe we will have multi-type events in practice. >>> Session cancellation can occur for many reasons. One of the >>> differentiators we had tried to make was an assumption that user >>> initiated events would be part of connect. Risk would cover >>> variations that drive off of risk calculations like password reset. >>> There are also signout events at rp's to let the OP know. These are >>> not commands but notification that a resource session is cancelled. >>> IOW single sign out not expected. >>> >>> Phil >>> >>> >>> On Jun 21, 2017, at 1:58 PM, John Bradley >> > wrote: >>> >>>> I thought we decided that we are only allowing set messages form >>>> the same family that agree on top level claims. >>>> Otherwise there can be no top level claims and we are really >>>> defining a alternative format to JWT in some ways. >>>> John B. >>>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle >>>>> > wrote: >>>>> I agree with John that the JWT type confusion problem and the SET >>>>> sub problem can and should be discussed separately. The secevents >>>>> WG is probably not the right setting to discuss the former. >>>>> My concern with the sub claim is that two profiles may dictate >>>>> conflicting semantics (e.g. Profile A says its a phone number, >>>>> Profile B says its an email address). If these profiles dont >>>>> provide an alternate way to declare subject of their events, then >>>>> they cannot be present within the same token. This incompatibility >>>>> trap seems like something that could be easily missed by groups >>>>> profiling SET. >>>>> -- >>>>> Annabelle Richard Backman >>>>> Identity Services >>>>> *From:*John Bradley > >>>>> *Date:*Wednesday, June 21, 2017 at 1:39 PM >>>>> *To:*Yaron Sheffer >>>> > >>>>> *Cc:*Justin Richer >, >>>>> Marius Scurtescu >>>> >, Annabelle Richard >>>>> >, Phil Hunt >>>>> >, Michael >>>>> Jones >>>> >, ID Events Mailing List >>>>> >, Henk Birkholz >>>>> >>>> > >>>>> *Subject:*Re: [Id-event] solution for Id/Access Token confusion >>>>> and distinct SET issuer >>>>> In the envelope typ is a media/mime type. Registering >>>>> application/idt+jwt if we register jwt as a structured name sufix. >>>>> Using the cty is also possible. I need to think about what is >>>>> better but we can agree on a convention. >>>>> Not everything is going to be a set token like not every JWS is a JWT. >>>>> If we are going to define processing rules to stop collisions and >>>>> confusion around JWT for different purposes, we should just start >>>>> using the typ parameter based on the existing spec. >>>>> In general content sniffing if there is more than one option >>>>> eventually gets you into trouble. >>>>> I am not convinced that forcing there to be no sub at the top >>>>> level is a good idea. >>>>> It is not the way we should differentiate between SET and id_tokens. >>>>> If sub is not allowed at the top level people will do non SET JWT >>>>> for things where the subject is scoped to the iss of the token. >>>>> I think defining sub to be part of the event for cases where the >>>>> sub is scoped differently from the issuer of the token is fine, >>>>> but should not be required for all event types. >>>>> I think we should solve the confusion issue separately from the >>>>> sub issue. >>>>> Sorry I am at CIS so trying to catch up on lists. >>>>> John B. >>>>>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer >>>>> > wrote: >>>>>> So to summarize what I'm seeing on this thread: >>>>>> Everybody agrees with Marius's short-term solution, specific >>>>>> rules for "sub" and "iss" that can be defined in the SET spec. >>>>>> Almost everybody agrees on a long-term "usage" claim ("type" is >>>>>> taken) that should be defined elsewhere, e.g. in the JWT BCP. >>>>>> Did I miss anything? >>>>>> By the way, if we do add a "usage" claim, we need to also use it >>>>>> in the SET document before it is published. >>>>>> Thanks, >>>>>> Yaron >>>>>> On 15/06/17 22:08, Justin Richer wrote: >>>>>>> +1 to this as well. >>>>>>> Justin >>>>>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu >>>>>>>> > wrote: >>>>>>>> +1 to what Annabelle said. >>>>>>>> Also, Mike you are missing the other requirement, for RPs to >>>>>>>> send events to an IdP. The iss+sub pair at the top level is >>>>>>>> broken in this case. >>>>>>>> >>>>>>>> Marius >>>>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) >>>>>>>> > wrote: >>>>>>>>> +1 >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle >>>>>>>>> > wrote: >>>>>>>>>> Mike, >>>>>>>>>> Your explanation for why this is a non-problem is dependent >>>>>>>>>> upon side effects of elements of OpenID Connect that were not >>>>>>>>>> designed to solve this issue. As a result, I see several >>>>>>>>>> issues with it: >>>>>>>>>> >>>>>>>>>> 1.The caller of the Token Endpoint is the only party that can >>>>>>>>>> be certain that a nonce-less ID Token is really an ID Token. >>>>>>>>>> Any party that the caller passes the ID Token off to has no >>>>>>>>>> way to verify its provenance. >>>>>>>>>> >>>>>>>>>> 2.Any future ID Token distribution method needs to solve this >>>>>>>>>> problem again. >>>>>>>>>> >>>>>>>>>> 3.No other profile of JWT can ever use the "nonce claim. >>>>>>>>>> >>>>>>>>>> 4.This is only a solution for ID Tokens. Every other JWT >>>>>>>>>> profile that cares about disambiguation has to invent its own >>>>>>>>>> solution to the problem. >>>>>>>>>> >>>>>>>>>> We know from experience that naming collisions and replay >>>>>>>>>> attacks are both things that happen. Whats being proposed is >>>>>>>>>> a simple, defensive measure against these risks. You brought >>>>>>>>>> up JWT libraries: a general solution actually makes it easier >>>>>>>>>> to use common libraries for JWT parsing. A usage-aware JWT >>>>>>>>>> library could handle disambiguation for any JWT profile, >>>>>>>>>> whereas with the status quo each profile would require unique >>>>>>>>>> logic. >>>>>>>>>> -- >>>>>>>>>> Annabelle Richard Backman >>>>>>>>>> Identity Services >>>>>>>>>> *From:*Id-event >>>>>>>>> > on behalf of Mike Jones >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> *Date:*Wednesday, June 14, 2017 at 1:16 PM >>>>>>>>>> *To:*Marius Scurtescu >>>>>>>>> > >>>>>>>>>> *Cc:*"Richard Backman, Annabelle" >>>>>>>>> >, ID Events Mailing List >>>>>>>>>> >, Henk Birkholz >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token >>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>> Youve heard of premature optimization. Id characterize >>>>>>>>>> the proposals in this thread as premature pessimation >>>>>>>>>> making things that can and should be simple complex, without >>>>>>>>>> data showing theres any need to do so. >>>>>>>>>> Mandatory solutions are being proposed in this thread to >>>>>>>>>> problems that theres no evidence that we actually even >>>>>>>>>> have. Its already been established that its impossible for >>>>>>>>>> a SET to be confused for an ID Token >>>>>>>>>> seehttps://www.ietf.org/mail-archive/web/id-event/current/msg00428.html >>>>>>>>>> . >>>>>>>>>> If people have data showing that this is possible with >>>>>>>>>> specific kinds of Access Tokens or other real JWT >>>>>>>>>> deployments, please provide specifics, so that we can use >>>>>>>>>> that data to inform appropriate engineering choices on our part. >>>>>>>>>> The proposed solutions, such as prohibiting the use of >>>>>>>>>> sub in the normal way, or requiring a type claim, would >>>>>>>>>> make previously simple things unnecessarily complex. Yes, >>>>>>>>>> then the result is then different than a normal JWT but a >>>>>>>>>> consequence of this is that custom parsing code would have to >>>>>>>>>> be used, rather than a standard JWT parser. The more >>>>>>>>>> unwieldy we make it to use SETs, the more likely developers >>>>>>>>>> are to just create their own data structures. Keeping it >>>>>>>>>> simple is the key to adoption. Standards are only useful if >>>>>>>>>> they are actually used. >>>>>>>>>> -- Mike >>>>>>>>>> *From:*Id-event [mailto:id-event-bounces@ietf.org]*On Behalf >>>>>>>>>> Of*Richard Backman, Annabelle >>>>>>>>>> *Sent:*Tuesday, June 13, 2017 5:33 PM >>>>>>>>>> *To:*Marius Scurtescu >>>>>>>>> >; Henk Birkholz >>>>>>>>>> >>>>>>>>> > >>>>>>>>>> *Cc:*ID Events Mailing List >>>>>>>>> > >>>>>>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token >>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>> Echoing Mariuss question: can you explain what you mean by >>>>>>>>>> intend? >>>>>>>>>> To your first question, I think a better analogy would be the >>>>>>>>>> X.509 Key Usage extension: a multi-valued property that >>>>>>>>>> declares the intended purpose of the JWT, and that a >>>>>>>>>> recipient may refer to when determining whether to accept a >>>>>>>>>> JWT being presented to it in some context. >>>>>>>>>> -- >>>>>>>>>> Annabelle Richard Backman >>>>>>>>>> Identity Services >>>>>>>>>> *From:*Id-event >>>>>>>>> > on behalf of Marius >>>>>>>>>> Scurtescu > >>>>>>>>>> *Date:*Tuesday, June 13, 2017 at 11:05 AM >>>>>>>>>> *To:*Henk Birkholz >>>>>>>>> > >>>>>>>>>> *Cc:*ID Events Mailing List >>>>>>>>> > >>>>>>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token >>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>>> And a 2nd question. >>>>>>>>>>> >>>>>>>>>>> What semantics would "usage" provide that that are not >>>>>>>>>>> covered via "intend", "audience", and "scope"? >>>>>>>>>> "aud" (audience) specifies the target client, but not the >>>>>>>>>> intended usage (access token to authorize resource access or >>>>>>>>>> SET to communicate a security event?) >>>>>>>>>> "scope" is not used by SET. >>>>>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Henk >>>>>>>>>>> >>>>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>> >>>>>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>>>> >>>>>>>>>>>> We cant guarantee that every type of JWT will have a >>>>>>>>>>>> mutually exclusive set of valid claims and/or header >>>>>>>>>>>> parameters, and enforcing this requires a fail on an >>>>>>>>>>>> unrecognized claim approach to ensure that JWTs from some >>>>>>>>>>>> future spec cant be mistaken for JWTs from a current spec. >>>>>>>>>>>> >>>>>>>>>>>> It is unrealistic to expect implementers to adhere to the >>>>>>>>>>>> different keys for different kinds of JWTs rule. Whether >>>>>>>>>>>> mandated by the spec or not, implementers will ignore this >>>>>>>>>>>> because managing one key is easier than managing N >>>>>>>>>>>> different keys. >>>>>>>>>>>> >>>>>>>>>>>> Ditto for aud and iss claims. >>>>>>>>>>>> >>>>>>>>>>>> +1 for a type or usage claim/header parameter. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>> >>>>>>>>>>>> Identity Services >>>>>>>>>>>> >>>>>>>>>>>> *From: *Id-event >>>>>>>>>>> > on behalf of Dick Hardt >>>>>>>>>>>> > >>>>>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>>>>> *To: *Marius Scurtescu >>>>>>>>>>> > >>>>>>>>>>>> *Cc: *Adam Dawes >>>>>>>>>>> >, "matake, nov" >>>>>>>>>>> >, ID Events Mailing List >>>>>>>>>>>> >, "Phil Hunt >>>>>>>>>>>> (IDM)" > >>>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token >>>>>>>>>>>> confusion and distinct SET issuer >>>>>>>>>>>> >>>>>>>>>>>> Agreed. Note that there is still lots of discussion on what >>>>>>>>>>>> should be in 3.9. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>>>> >>>>>>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" >>>>>>>>>>>> and the >>>>>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive >>>>>>>>>>>> Validation Rules for >>>>>>>>>>>> Different Kinds of JWTs", specifically "Use different >>>>>>>>>>>> sets of >>>>>>>>>>>> required claims...", "Use different keys for different >>>>>>>>>>>> kinds of >>>>>>>>>>>> JWTs." and "Use different issuers for different kinds >>>>>>>>>>>> of JWTs.". >>>>>>>>>>>> >>>>>>>>>>>> I still think that a "type" claim would bring a lot of >>>>>>>>>>>> clarity and >>>>>>>>>>>> safety. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Marius >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>>>>> http://self-issued.info/?p=1690 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes >>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I was initially a fan of keeping SETS to be >>>>>>>>>>>> very similar to >>>>>>>>>>>> id tokens but I now think this is a better plan. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov >>>>>>>>>>>> >>>>>>>>>>>> >> wrote: >>>>>>>>>>>> >>>>>>>>>>>> +1 especially for "type" >>>>>>>>>>>> >>>>>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>: >>>>>>>>>>>> >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>> Phil >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > There were a couple of proposals on how to >>>>>>>>>>>> distinguish SETs from Id Tokens and Access Tokens in >>>>>>>>>>>> such a way that naive implementations will not >>>>>>>>>>>> confuse one for the other and open up security >>>>>>>>>>>> vulnerabilities. >>>>>>>>>>>> > >>>>>>>>>>>> > There is also another important requirement: the >>>>>>>>>>>> SET issuer in some cases must be different from the >>>>>>>>>>>> "sub" issuer. This is the case of an RP sending SETs >>>>>>>>>>>> to an IdP. >>>>>>>>>>>> > >>>>>>>>>>>> > With these requirements in mind I propose the >>>>>>>>>>>> following: >>>>>>>>>>>> > - both "sub" and "iss" to be defined at the event >>>>>>>>>>>> level >>>>>>>>>>>> > - "iss" at event level and at top SET level can >>>>>>>>>>>> be different >>>>>>>>>>>> > - "iss" and "sub" at event level can be different >>>>>>>>>>>> across events in the same SET >>>>>>>>>>>> > - "sub" should NOT be present at the top SET >>>>>>>>>>>> level (this solves the disambiguation), please note >>>>>>>>>>>> "should" and not "must" >>>>>>>>>>>> > >>>>>>>>>>>> > This solution also allows different profiles that >>>>>>>>>>>> define event types to define additional claims >>>>>>>>>>>> related to sub (like email or phone_number) and >>>>>>>>>>>> since all these claims will be at the event level >>>>>>>>>>>> there will be no collisions or ambiguity. >>>>>>>>>>>> > >>>>>>>>>>>> > Another proposal (which I supported) was to >>>>>>>>>>>> define a composite "aud" claim. This is not solving >>>>>>>>>>>> the requirement for a distinct SET issuer. Also, >>>>>>>>>>>> having the same claim name having different syntax >>>>>>>>>>>> in different token types could lead to confusion. >>>>>>>>>>>> > >>>>>>>>>>>> > And yet another proposal was to introduce a new >>>>>>>>>>>> claim for JWTs that defines a "type". This is not >>>>>>>>>>>> practical in the short term, and it also is not >>>>>>>>>>>> solving the distinct issuer requirement, but I think >>>>>>>>>>>> this is something the JWT group should seriously >>>>>>>>>>>> consider. >>>>>>>>>>>> > >>>>>>>>>>>> > Thoughts? >>>>>>>>>>>> > >>>>>>>>>>>> > Marius >>>>>>>>>>>> >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > Id-event mailing list >>>>>>>>>>>> >>>>>>>>>>>> >Id-event@ietf.org >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Adam Dawes | Sr. Product Manager |adawes@google.com >>>>>>>>>>>> >>>>>>>>>>>> > |+1 >>>>>>>>>>>> 650-214-2410 >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Subscribe to the HARDTWARE >>>>>>>>>>> > >>>>>>>>>>>> mail list to >>>>>>>>>>>> learn about projects I am working on! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Subscribe to the HARDTWARE >>>>>>>>>>> > >>>>>>>>>>>> mail list to learn about projects I am working on! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Id-event mailing list >>>>>>>>>> Id-event@ietf.org >>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e= >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>> >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> > --------------23AD7323520B4A5B083042E7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Mike, this is not at all what I see for having the "most support". Instead I'm seeing a lot of call for having "sub" defined clearly in the event payload only.

The "sub" of the main body is the subject as known by the issuer of the SET itself. This might be the same subject that the subject is known by at the target of the SET. There are many cases where this isn't true, and so far one exception case where it is, sometimes. We should not be writing this for the exception.

But I think there's a pretty clear path forward. The "sub" in the body of a SET, if it is included, is *ALWAYS* in the context of the "iss" of the SET. Always, full stop, no exceptions. No global namespaces, no restrictions on content, no formats -- it's an opaque (to the SET standard) value in the domain of the issuer of the SET.

Event payloads, defined in profiles, describe a subject of the event itself. Importantly, this is the subject as known by the context in which the event will be *received*, not in which it was *issued*. Sometimes those are the same, more often (as we're seeing) we can't guarantee that. We should not depend on that and we should not treat the exceptional case as the usual, no matter what syntax another group has come up with.

So here's the thing. I think the "sub" of an event should be optional, and ALWAYS in the context of the issuer, and profiles should not places further constraints on that. Events themselves should be self-contained. I regret that we didn't make the registration object in RFC7591 more self-contained, as that's caused implementation and extension issues. I think events should always have an internal subject/issuer pair, in the context of where the event is being consumed. We need to define what iss/sub mean (in a grand sense) inside the event object in this document, so that different events don't reinvent the same thing over and over. If a profile wants to leave that out because they don't need an identifier for the payload, then they can leave it out. If they want to leave it out because they want to assume there will "always" be an iss/sub in the root of the SET, then I have a problem with that. The issuer of the SET can, and probably does, have its own identifier which can't be assumed to be universal. Proposing a global subject namespace or format, as has been suggested elsewhere on this list, is ludicrous and will never fly as it goes against how JWT namespacing for people and objects has always worked. We should have a clear semantic data structure that can be extended and used by all of the use cases that we've adopted. Optimizing at this stage, especially based on one event, is going to just lead to things being broken and back-patched later on. But if one spec wants to leave out the iss/sub inside the event? They can still do that, but I think that's pretty daft.


In summary:

  • iss: issuer of the event
  • sub: subject of the event as known by the issuer of the event
  • event.sub: subject of the event as known by the recipient of the event
  • event.iss: context for the subject of the event as known by the recipient of the event
  • event.aud: recipient of the event


-- Justin


On 6/21/2017 7:45 PM, Mike Jones wrote:

The proposal that I believe has the most support is keeping things as they are, leaving it up to profiles and applications to define which claims they use and how they use them.

It would be fine for some profiles to use the language below.

Mike

From: Phil Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

So I understand what is being proposed is:

If the event type uses sub to identify its subject, and the issuer of the subject is identical to the issuer for the event, then sub may be used at the top level. Otherwise, the subject of an event (e.g. sub) and any other claims required to uniquely identify the subject MUST be contained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a ipaddress claim defined in the event payload. ipaddress:1.2.3.4"

A Connect Logout event from an OP uses the top level sub claim and depends on iss being the same for the event issuer AND the subject. This means that no party may issue logout events on behalf of the OP.


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Fair point. If we do not intend to support multiple profiles within a single SET, then Im less concerned about leaving sub semantics up to the profiles.
--
Annabelle Richard Backman
Identity Services
From:Marius Scurtescu <mscurtescu@google.com>
Date:Wednesday, June 21, 2017 at 2:58 PM
To:"Richard Backman, Annabelle" <richanna@amazon.com>
Cc:"Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>
Subject:Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
Example for multiple events within same profile: IdP account is disabled (because of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the events claim SHOULD NOT be used to express multiple logical events. If its also not used to express events from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then Im not sure what use case that leaves for multiple events in one SET.
--
Annabelle Richard Backman
Identity Services
From:Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Date:Wednesday, June 21, 2017 at 2:12 PM
To:John Bradley <ve7jtb@ve7jtb.com>
Cc:"Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>

Subject:Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
Separate or combined may be evolving. Mike wants to keep the current backchannel logout very narrowly scoped. He suggested risc define its own duplicate definitions and meanings.
That leads me to believe we will have multi-type events in practice.
Session cancellation can occur for many reasons. One of the differentiators we had tried to make was an assumption that user initiated events would be part of connect. Risk would cover variations that drive off of risk calculations like password reset.
There are also signout events at rp's to let the OP know. These are not commands but notification that a resource session is cancelled. IOW single sign out not expected.

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing set messages form the same family that agree on top level claims.
Otherwise there can be no top level claims and we are really defining a alternative format to JWT in some ways.
John B.
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
I agree with John that the JWT type confusion problem and the SET sub problem can and should be discussed separately. The secevents WG is probably not the right setting to discuss the former.
My concern with the sub claim is that two profiles may dictate conflicting semantics (e.g. Profile A says its a phone number, Profile B says its an email address). If these profiles dont provide an alternate way to declare subject of their events, then they cannot be present within the same token. This incompatibility trap seems like something that could be easily missed by groups profiling SET.
--
Annabelle Richard Backman
Identity Services
From:John Bradley <ve7jtb@ve7jtb.com>
Date:Wednesday, June 21, 2017 at 1:39 PM
To:Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
In the envelope typ is a media/mime type. Registering application/idt+jwt if we register jwt as a structured name sufix.
Using the cty is also possible. I need to think about what is better but we can agree on a convention.
Not everything is going to be a set token like not every JWS is a JWT.
If we are going to define processing rules to stop collisions and confusion around JWT for different purposes, we should just start using the typ parameter based on the existing spec.
In general content sniffing if there is more than one option eventually gets you into trouble.
I am not convinced that forcing there to be no sub at the top level is a good idea.
It is not the way we should differentiate between SET and id_tokens.
If sub is not allowed at the top level people will do non SET JWT for things where the subject is scoped to the iss of the token.
I think defining sub to be part of the event for cases where the sub is scoped differently from the issuer of the token is fine, but should not be required for all event types.
I think we should solve the confusion issue separately from the sub issue.
Sorry I am at CIS so trying to catch up on lists.
John B.
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.
Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.
Thanks,
Yaron
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well.
Justin
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
+1 to what Annabelle said.
Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

Marius
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
Phil

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.Any future ID Token distribution method needs to solve this problem again.

3.No other profile of JWT can ever use the "nonce claim.

4.This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

We know from experience that naming collisions and replay attacks are both things that happen. Whats being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A usage-aware JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.
--
Annabelle Richard Backman
Identity Services
From:Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date:Wednesday, June 14, 2017 at 1:16 PM
To:Marius Scurtescu <mscurtescu@google.com>
Cc:"Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
Youve heard of premature optimization. Id characterize the proposals in this thread as premature pessimation making things that can and should be simple complex, without data showing theres any need to do so.
Mandatory solutions are being proposed in this thread to problems that theres no evidence that we actually even have. Its already been established that its impossible for a SET to be confused for an ID Token seehttps://www.ietf.org/mail-archive/web/id-event/current/msg00428.html. If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
The proposed solutions, such as prohibiting the use of sub in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex. Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser. The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures. Keeping it simple is the key to adoption. Standards are only useful if they are actually used.
-- Mike
From:Id-event [mailto:id-event-bounces@ietf.org]On Behalf OfRichard Backman, Annabelle
Sent:Tuesday, June 13, 2017 5:33 PM
To:Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:ID Events Mailing List <id-event@ietf.org>
Subject:Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
Echoing Mariuss question: can you explain what you mean by intend?
To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.
--
Annabelle Richard Backman
Identity Services
From:Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@google.com>
Date:Tuesday, June 13, 2017 at 11:05 AM
To:Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:ID Events Mailing List <id-event@ietf.org>
Subject:Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.

What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?
"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)
"scope" is not used by SET.
I don't know what do you mean by "intend" (or intent)?


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

We cant guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a fail on an unrecognized claim approach to ensure that JWTs from some future spec cant be mistaken for JWTs from a current spec.

It is unrealistic to expect implementers to adhere to the different keys for different kinds of JWTs rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

Ditto for aud and iss claims.

+1 for a type or usage claim/header parameter.

--

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam Dawes <adawes@google.com>, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

Thanks for the pointer Dick, very good timing :-)

The issue is described by "2.7. Cross-JWT Confusion" and the
mitigation is in "3.9. Use Mutually Exclusive Validation Rules for
Different Kinds of JWTs", specifically "Use different sets of
required claims...", "Use different keys for different kinds of
JWTs." and "Use different issuers for different kinds of JWTs.".

I still think that a "type" claim would bring a lot of clarity and
safety.


Marius

On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
<mailto:dick.hardt@gmail.com>> wrote:

Yaron, Mike and I just published an BCP ID for JWT
http://self-issued.info/?p=1690

On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com
<mailto:adawes@google.com>> wrote:

I was initially a fan of keeping SETS to be very similar to
id tokens but I now think this is a better plan.

On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
<mailto:nov@matake.jp>> wrote:

+1 especially for "type"

2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
<phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

+1

Phil


> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
<mscurtescu@google.com
<mailto:mscurtescu@google.com>> wrote:
>
> There were a couple of proposals on how to
distinguish SETs from Id Tokens and Access Tokens in
such a way that naive implementations will not
confuse one for the other and open up security
vulnerabilities.
>
> There is also another important requirement: the
SET issuer in some cases must be different from the
"sub" issuer. This is the case of an RP sending SETs
to an IdP.
>
> With these requirements in mind I propose the
following:
> - both "sub" and "iss" to be defined at the event
level
> - "iss" at event level and at top SET level can
be different
> - "iss" and "sub" at event level can be different
across events in the same SET
> - "sub" should NOT be present at the top SET
level (this solves the disambiguation), please note
"should" and not "must"
>
> This solution also allows different profiles that
define event types to define additional claims
related to sub (like email or phone_number) and
since all these claims will be at the event level
there will be no collisions or ambiguity.
>
> Another proposal (which I supported) was to
define a composite "aud" claim. This is not solving
the requirement for a distinct SET issuer. Also,
having the same claim name having different syntax
in different token types could lead to confusion.
>
> And yet another proposal was to introduce a new
claim for JWTs that defines a "type". This is not
practical in the short term, and it also is not
solving the distinct issuer requirement, but I think
this is something the JWT group should seriously
consider.
>
> Thoughts?
>
> Marius

> _______________________________________________
> Id-event mailing list

>Id-event@ietf.org<mailto:Id-event@ietf.org>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event

--
Adam Dawes | Sr. Product Manager |adawes@google.com
<mailto:adawes@google.com> |+1 650-214-2410
<tel:(650)%20214-2410>

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event

--
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
learn about projects I am working on!



--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--------------23AD7323520B4A5B083042E7-- From nobody Mon Jun 26 09:43:29 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE2812EAED for ; Mon, 26 Jun 2017 09:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b6Pm71-kWpe for ; Mon, 26 Jun 2017 09:43:23 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B905B129BC4 for ; Mon, 26 Jun 2017 09:43:22 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id b205so1792255itg.1 for ; Mon, 26 Jun 2017 09:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MMA/h3rm6G9sPiZhcZBQzcjbyehSE/coN7mcRezs7pw=; b=LFqFEw4fuiRbdPExs0xkqZT0KfT9sV2cYNMq5kXv/45+zHTex+JQxwWm6DxaodsR4B 9VovH6TdkLEuIXFmkKEC31u2UBzbh6egdo4gNjkEtajiIYiRHFpTJBKKJNfFaIpWBAZ6 /RvrbWWZEEL5r0UqK1jqaHAAyfjd0EntDVY83hhdANMOXJaNYoF26vCc7ojqloxuDgC7 AkEbT7eYwQLJ8NtIp3pNr1AO6hcXFkrM0SJxFGIJeV3LBVvg/dIW6dWgXRcXufCTCK19 3Dc6vucW0x2CxQMSF3s36ULNL6wzCCtWBR24B9G8hatDbjAStRzdc/igrp9iQhwFqxcJ mN6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MMA/h3rm6G9sPiZhcZBQzcjbyehSE/coN7mcRezs7pw=; b=uPR6nU6/rGMQeuJCqxcloLYikMjGEaeMqALNujxbefat2QJGrLLA1QHh/dIfQAtII7 2v4zNs78RgNY4ZmXFEriU3jEmr16H0XtMnXUX+8uu+bkYfXR6qwiNo+jW4Pp5i7cjjUG +sHqxSjvfDBf9/bw6pNwU1fZmzomKYv6XGokNjTUSuYNIdJFFuzU6J78NVTZXEe0R1o/ c9sCifm3oI9wdrHUegmrcyNmFD1X/Pk4gO+hT+w3xN94k0/3yGHngvMS0TWbjY9qtPSV 2gQUT98uaaC6r37cE0qXvTKY3g8OjF8XS7zXy7X9eVk+KNMx3LVU56a8mX0Ynav4G7/L ulvg== X-Gm-Message-State: AKS2vOxzysyDufOuO0QmtepVwzQuNiAJnMIql1fyWCDYy9WtDuP6YWKd Hiag62x4vRtvYmsdB2nH5BPIm/OzhBzL X-Received: by 10.36.27.72 with SMTP id 69mr364107its.116.1498495401465; Mon, 26 Jun 2017 09:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Mon, 26 Jun 2017 09:43:00 -0700 (PDT) In-Reply-To: <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> From: Marius Scurtescu Date: Mon, 26 Jun 2017 09:43:00 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Phil Hunt , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a114495b61ae5fa0552dfa6c6" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 16:43:28 -0000 --001a114495b61ae5fa0552dfa6c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, in the case when an RP is issuing the SET to send it to an IdP, a top level sub as you describe it may not be possible. Or maybe I misunderstand. We agree on "iss" I think, in this case it points to the RP. A top level "sub" though is problematic, The RP in many cases has the opaque "sub" as issued by the IdP, but this value is globally unique only when combined with the IdP "iss". Not sure why event.aud would be necessary? Marius On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer wrote: > Mike, this is not at all what I see for having the "most support". Instea= d > I'm seeing a lot of call for having "sub" defined clearly in the event > payload only. > > The "sub" of the main body is the subject as known by the issuer of the > SET itself. This might be the same subject that the subject is known by a= t > the target of the SET. There are many cases where this isn't true, and so > far one exception case where it is, sometimes. We should not be writing > this for the exception. > > But I think there's a pretty clear path forward. The "sub" in the body of > a SET, if it is included, is *ALWAYS* in the context of the "iss" of the > SET. Always, full stop, no exceptions. No global namespaces, no > restrictions on content, no formats -- it's an opaque (to the SET standar= d) > value in the domain of the issuer of the SET. > > Event payloads, defined in profiles, describe a subject of the event > itself. Importantly, this is the subject as known by the context in which > the event will be *received*, not in which it was *issued*. Sometimes tho= se > are the same, more often (as we're seeing) we can't guarantee that. We > should not depend on that and we should not treat the exceptional case as > the usual, no matter what syntax another group has come up with. > > So here's the thing. I think the "sub" of an event should be optional, an= d > ALWAYS in the context of the issuer, and profiles should not places furth= er > constraints on that. Events themselves should be self-contained. I regret > that we didn't make the registration object in RFC7591 more self-containe= d, > as that's caused implementation and extension issues. I think events shou= ld > always have an internal subject/issuer pair, in the context of where the > event is being consumed. We need to define what iss/sub mean (in a grand > sense) inside the event object in this document, so that different events > don't reinvent the same thing over and over. If a profile wants to leave > that out because they don't need an identifier for the payload, then they > can leave it out. If they want to leave it out because they want to assum= e > there will "always" be an iss/sub in the root of the SET, then I have a > problem with that. The issuer of the SET can, and probably does, have its > own identifier which can't be assumed to be universal. Proposing a global > subject namespace or format, as has been suggested elsewhere on this list= , > is ludicrous and will never fly as it goes against how JWT namespacing fo= r > people and objects has always worked. We should have a clear semantic dat= a > structure that can be extended and used by all of the use cases that we'v= e > adopted. Optimizing at this stage, especially based on one event, is goin= g > to just lead to things being broken and back-patched later on. But if one > spec wants to leave out the iss/sub inside the event? They can still do > that, but I think that's pretty daft. > > > In summary: > > - iss: issuer of the event > - sub: subject of the event as known by the issuer of the event > - event.sub: subject of the event as known by the recipient of the > event > - event.iss: context for the subject of the event as known by the > recipient of the event > - event.aud: recipient of the event > > > -- Justin > > On 6/21/2017 7:45 PM, Mike Jones wrote: > > The proposal that I believe has the most support is keeping things as the= y > are, leaving it up to profiles and applications to define which claims th= ey > use and how they use them. > > > > It would be fine for some profiles to use the language below. > > > > =E2=80=93 Mike > > *From: *Phil Hunt > *Sent: *Wednesday, June 21, 2017 6:39 PM > *To: *Richard Backman, Annabelle > *Cc: *Marius Scurtescu ; John Bradley > ; Henk Birkholz ; Jus= tin > Richer ; Yaron Sheffer ; Mike > Jones ; ID Events Mailing List > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > So I understand what is being proposed is: > > If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, and= the issuer of > the subject is identical to the issuer for the event, then =E2=80=9Csub= =E2=80=9D may be > used at the top level. Otherwise, the subject of an event (e.g. =E2=80=9C= sub=E2=80=9D) and > any other claims required to uniquely identify the subject MUST be > contained in the event payload. > > For example, an ip address of 1.2.3.4 might be represented in a > =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. =E2=80=9C= ipaddress=E2=80=9D:=E2=80=9D1.2.3.4" > A SCIM resource URI of https://scim.example.com/users/ > ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload > as: =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45c= e9a242bd3859c82c4 > =E2=80=9D > > A Connect Logout event from an OP uses the top level sub claim and depend= s > on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the subj= ect. This means > that no party may issue logout events on behalf of the OP. > > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Fair point. If we do not intend to support multiple profiles within a > single SET, then I=E2=80=99m less concerned about leaving sub semantics u= p to the > profiles. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Marius Scurtescu > *Date: *Wednesday, June 21, 2017 at 2:58 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"Phil Hunt (IDM)" , John Bradley < > ve7jtb@ve7jtb.com>, Henk Birkholz , > Justin Richer , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Example for multiple events within same profile: IdP account is disabled > (because of hijacking), this can lead to two events: > 1. "account-disabled" > 2. "sessions-revoked" > > Marius > > On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The spec says that the events claim SHOULD NOT be used to express multipl= e > logical events. If it=E2=80=99s also not used to express events from diff= erent > profiles that correspond to the same logical event (e.g. an OIDC > backchannel logout event alongside a hypothetical RISC logout event), the= n > I=E2=80=99m not sure what use case that leaves for multiple events in one= SET. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Id-event on behalf of "Phil Hunt > (IDM)" > *Date: *Wednesday, June 21, 2017 at 2:12 PM > *To: *John Bradley > *Cc: *"Richard Backman, Annabelle" , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>, Justin Richer , Marius > Scurtescu , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Separate or combined may be evolving. Mike wants to keep the current > backchannel logout very narrowly scoped. He suggested risc define its own > duplicate definitions and meanings. > > That leads me to believe we will have multi-type events in practice. > > Session cancellation can occur for many reasons. One of the > differentiators we had tried to make was an assumption that user initiate= d > events would be part of connect. Risk would cover variations that drive o= ff > of risk calculations like password reset. > > There are also signout events at rp's to let the OP know. These are not > commands but notification that a resource session is cancelled. IOW singl= e > sign out not expected. > > Phil > > > On Jun 21, 2017, at 1:58 PM, John Bradley wrote: > > I thought we decided that we are only allowing set messages form the same > family that agree on top level claims. > > Otherwise there can be no top level claims and we are really defining a > alternative format to JWT in some ways. > > John B. > > > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > I agree with John that the JWT type confusion problem and the SET sub > problem can and should be discussed separately. The secevents WG is > probably not the right setting to discuss the former. > > My concern with the sub claim is that two profiles may dictate conflictin= g > semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B say= s it=E2=80=99s an > email address). If these profiles don=E2=80=99t provide an alternate way = to declare > subject of their events, then they cannot be present within the same toke= n. > This incompatibility trap seems like something that could be easily misse= d > by groups profiling SET. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *John Bradley > *Date: *Wednesday, June 21, 2017 at 1:39 PM > *To: *Yaron Sheffer > *Cc: *Justin Richer , Marius Scurtescu < > mscurtescu@google.com>, Annabelle Richard , Phil > Hunt , Michael Jones , > ID Events Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > In the envelope typ is a media/mime type. Registering application/idt+jw= t > if we register jwt as a structured name sufix. > > Using the cty is also possible. I need to think about what is better bu= t > we can agree on a convention. > > Not everything is going to be a set token like not every JWS is a JWT. > > If we are going to define processing rules to stop collisions and > confusion around JWT for different purposes, we should just start using t= he > typ parameter based on the existing spec. > > In general content sniffing if there is more than one option eventually > gets you into trouble. > > I am not convinced that forcing there to be no sub at the top level is a > good idea. > > It is not the way we should differentiate between SET and id_tokens. > > If sub is not allowed at the top level people will do non SET JWT for > things where the subject is scoped to the iss of the token. > > I think defining sub to be part of the event for cases where the sub is > scoped differently from the issuer of the token is fine, but should not b= e > required for all event types. > > I think we should solve the confusion issue separately from the sub issue= . > > Sorry I am at CIS so trying to catch up on lists. > > John B. > > > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote: > > So to summarize what I'm seeing on this thread: > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > Did I miss anything? > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > Thanks, > Yaron > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > =E2=80=94 Justin > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > +1 to what Annabelle said. > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > Marius > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > Phil > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > -- > Annabelle Richard Backman > Identity Services > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > "scope" is not used by SET. > > I don't know what do you mean by "intend" (or intent)? > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > <%2B1%20650-214-2410> > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > --001a114495b61ae5fa0552dfa6c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin, in the case when an RP is issuing the SET to send = it to an IdP, a top level sub as you describe it may not be possible. Or ma= ybe I misunderstand.

We agree on "iss" I think= , in this case it points to the RP. A top level "sub" though is p= roblematic, The RP in many cases has the opaque "sub" as issued b= y the IdP, but this value is globally unique only when combined with the Id= P "iss".

Not sure why event.aud would be= necessary?

Marius

On Sun, Jun 25, 2017 at 7:31 AM, Justin Rich= er <jricher@mit.edu> wrote:
=20 =20 =20

Mike, this is not at all what I see for having the "most support". Instead I'm seeing a lot of call for having "= sub" defined clearly in the event payload only.

The "sub" of the main body is the subject as known by the = issuer of the SET itself. This might be the same subject that the subject is known by at the target of the SET. There are many cases where this isn't true, and so far one exception case where it is, sometimes. We should not be writing this for the exception.

But I think there's a pretty clear path forward. The "sub&q= uot; in the body of a SET, if it is included, is *ALWAYS* in the context of the "iss" of the SET. Always, full stop, no exceptions. No = global namespaces, no restrictions on content, no formats -- it's an opaque (to the SET standard) value in the domain of the issuer of the SET.

Event payloads, defined in profiles, describe a subject of the event itself. Importantly, this is the subject as known by the context in which the event will be *received*, not in which it was *issued*. Sometimes those are the same, more often (as we're seeing) we can't guarantee that. We should not depend on that and we should not treat the exceptional case as the usual, no matter what syntax another group has come up with.

So here's the thing. I think the "sub" of an event sho= uld be optional, and ALWAYS in the context of the issuer, and profiles should not places further constraints on that. Events themselves should be self-contained. I regret that we didn't make the registration object in RFC7591 more self-contained, as that's caused implementation and extension issues. I think events should always have an internal subject/issuer pair, in the context of where the event is being consumed. We need to define what iss/sub mean (in a grand sense) inside the event object in this document, so that different events don't reinvent the same thing over and over. If a profile wants to leave that out because they don't nee= d an identifier for the payload, then they can leave it out. If they want to leave it out because they want to assume there will "always" be an iss/sub in the root of the SET, then I have = a problem with that. The issuer of the SET can, and probably does, have its own identifier which can't be assumed to be universal. Proposing a global subject namespace or format, as has been suggested elsewhere on this list, is ludicrous and will never fly as it goes against how JWT namespacing for people and objects has always worked. We should have a clear semantic data structure that can be extended and used by all of the use cases that we've adopted. Optimizing at this stage, especially based on one event, is going to just lead to things being broken and back-patched later on. But if one spec wants to leave out the iss/sub inside the event? They can still do that, but I think that's pretty daft= .


In summary:

  • iss: issuer of the event
  • sub: subject of the event as known by the issuer of the event
  • event.sub: subject of the event as known by the recipient of the event
  • event.iss: context for the subject of the event as known by the recipient of the event
  • event.aud: recipient of the event


=C2=A0-- Justin


On 6/21/2017 7:45 = PM, Mike Jones wrote:
=20 =20 =20

The proposal that I believe has the most support is keeping things as they are, leaving it up to profiles and applications to define which claims they use and how they use them.

=C2=A0

It would be fine for some profiles to use the language below.

=C2=A0

=E2=80=93 Mike

From: P= hil Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

=C2=A0

So I understand what is being proposed is:

If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, and th= e issuer of the subject is identical to the issuer for the event, then =E2=80=9Csub=E2=80=9D may be used at the top level. Otherwise, = the subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims r= equired to uniquely identify the subject MUST be contained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a =E2=80=9Cipaddress=E2=80=9D claim defined in the= event payload. =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload as: =E2=80=9Csub=E2=80= =9D:"https://scim.example.com/users/ac1fa= ebbfd3c45ce9a242bd3859c82c4=E2=80=9D

A Connect Logout event from an OP uses the top level sub claim and depends on =E2=80=9Ciss=E2=80=9D being the sa= me for the event issuer AND the subject. This means that no party may issue logout events on behalf of the OP.


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Fair point. If we do not intend to support multiple profiles within a single SET, then I=E2=80=99m less concerned about lea= ving sub semantics up to the profiles.
=C2=A0
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0
=C2=A0
Fro= m:=C2=A0= Marius Scurtescu = <mscurtescu@g= oogle.com>
Date:=C2=A0Wednesday, June 21, 2017 at 2:58 PM
To:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>
Cc:=C2=A0"Phil Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>
Subject:=C2=A0Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
=C2=A0
Example for multiple events within same profile: IdP account is disabled (because of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
=C2=A0
On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the events claim SHOULD NOT be used to express multiple logical events. If it=E2=80=99s also not used to express ev= ents from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then I=E2=80=99m not sure what use case that lea= ves for multiple events in one SET.
=C2=A0
--=C2=A0
Annabelle Richard Backman
Identity Services
=C2=A0
=C2=A0
From:=C2= =A0Id-even= t <id-event-bounces@ietf.org>= ; on behalf of "Phil Hunt (IDM)" = <phil.hunt@oracle.com>
Date:=C2=A0Wednesday, June 21, 2017 at 2:12 PM
To:=C2=A0John Bradley <= ve7jtb@ve7jtb.com>
Cc:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>

Subject:=C2=A0Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
=C2=A0
Separate or combined may be evolving. Mike wants to keep the current backchannel logout very narrowly scoped. He suggested risc define its own duplicate definitions and meanings.=C2=A0
=C2=A0
That leads me to believe we will have multi-type events in practice.<= /u>
=C2=A0
Session cancellation can occur for many reasons. One of the differentiators we had tried to make was an assumption that user initiated events would be part of connect. Risk would cover variations that drive off of risk calculations like password reset.=C2=A0
=C2=A0
There are also signout events at rp's to let the OP know. These are not commands but notification that a resource session is cancelled. IOW single sign out not expected.=C2=A0<= /u>

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I thought we decided that we are only allowing set messages form the same family that agree on top level claims.
=C2=A0
Otherwise there can be no top level claims and we are really defining a alternative format to JWT in some ways.
=C2=A0
John B.
=C2=A0
On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
=C2=A0
I agree with John that the JWT type confusion problem and the SET sub problem can and should be discussed separately. The secevents WG is probably not the right setting to discuss the former.<= /u>
=C2=A0
My concern with the sub claim is that two profiles may dictate conflicting semantics (e.g. Profile A says it=E2=80= =99s a phone number, Profile B says it=E2=80=99s an em= ail address). If these profiles don=E2=80=99t pr= ovide an alternate way to declare subject of their events, then they cannot be present within the same token. This incompatibility trap seems like something that could be easily missed by groups profiling SET.
=C2=A0
--=C2=A0
Annabelle Richard Backman
Identity Services<= u>
=C2=A0
=C2=A0
From:=C2=A0John Bradley <ve7jtb@ve7jtb.com>
Date:=C2=A0Wednesday, June 21, 2017 at 1:39 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<= /a>>
Subject:=C2= =A0Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
=C2=A0
In the envelope typ is a media/mime type.=C2=A0 Registering application/idt+jwt if we register jwt as a structured name sufix. =C2= =A0
=C2=A0
Using the cty is also possible. =C2=A0 I need t= o think about what is better but we can agree on a convention.=
=C2=A0
Not everything is going to be a set token like not every JWS is a JWT.=
=C2=A0
If we are going to define processing rules to stop collisions and confusion around JWT for different purposes, we should just start using the typ parameter based on the existing spec.
=C2=A0
In general content sniffing if there is more than one option eventually gets you into trouble.=
=C2=A0
I am not convinced that forcing there to be no sub at the top level is a good idea. =C2=A0<= /u>
=C2=A0
It is not the way we should differentiate between SET and id_tokens.
=C2=A0<= /div>
If sub is not allowed at the top level people will do non SET JWT for things where the subject is scoped to the iss of the token.<= /div>
=C2=A0<= /div>
I think defining sub to be part of the event for cases where the sub is scoped differently from the issuer of the token is fine, but should not be required for all event types.
=C2=A0<= /div>
I think we should solve the confusion issue separately from the sub issue.=
=C2=A0<= /div>
Sorry I am at CIS so trying to catch up on lists.
=C2=A0<= /div>
John B.=
=C2=A0<= /div>
On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.= com> wrote:<= /u>
=C2=A0<= /u>
So to summarize what I'm seeing on this thread:
Everybody agrees with Marius's short-term solution, specific rules for "sub&quo= t; and "iss" t= hat can be defined in the SET spec.<= /u>
Almost everybody agrees on a long-term "usage"= claim ("type"= is taken) that should be defined elsewhere, e.g. in the JWT BCP.
Did I miss anything?<= u>
By the way, if we do add a "usage"= claim, we need to also use it in the SET document before it is published.=
Thanks,=
=C2=A0=C2=A0=C2= =A0 Yaron
=C2=A0<= /u>
On 15/06/17 22:08, Justin Richer wrote:<= /u>
+1 to this as well.=C2= =A0
=C2=A0<= /u>
=C2=A0=E2=80=94 J= ustin
=C2=A0<= /u>
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@googl= e.com> wrote:<= /u>
=C2=A0<= /u>
+1 to what Annabelle said.=C2= =A0
=C2=A0<= /u>
Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.

Marius<= /u>
=C2=A0<= /u>
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com= > wrote:<= /u>
+1<= /div>
=C2=A0<= /u>
Phil

=C2=A0<= /u>

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <richanna@amazon.co= m> wrote:<= /u>
Mike,
=C2=A0
Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Any future ID Token distribution method needs to solve this problem again.

3.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0No other profile of JWT can ever use the "nonce=E2=80= =9D claim.

4.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

=C2=A0
We know from experience that naming collisions and replay attacks are both things that happen. What=E2= =80=99s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A =E2=80=9Cusage-aw= are=E2=80=9D JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.
=C2=A0
--=C2=A0
Annabelle Richard Backman=
Identity Services
=C2=A0
=C2=A0
From:=C2=A0Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@micros= oft.com>
Date:=C2= =A0Wednesday, June 14, 2017 at 1:16 PM
To:=C2= =A0Marius Scurtescu <mscurtescu@googl= e.com>
Cc:=C2= =A0"Richard Backman, Annabelle" <richanna@amazon.com>, ID Events Mailing List <id-event@ietf.org&g= t;, Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Subject:= =C2=A0Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<= /u>
=C2=A0<= /u>
You=E2=80=99ve heard of =E2=80=9Cprematur= e optimization=E2= =80=9D.=C2=A0 I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprema= ture pessimation=E2=80= =9D =E2=80=93 making things that can and should be simple complex, without data showing there=E2=80=99s a= ny need to do so.
=C2=A0
Mandatory solutions are being proposed in this thread to problems that there=E2=80= =99s no evidence that we actually even have.=C2=A0 It=E2= =80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2= =80=93 see=C2=A0https://www.ietf.org/mail-archive/web/id-event/curre= nt/msg00428.html.=C2=A0 If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
=C2=A0
The proposed =E2=80=9Csolution= s=E2=80=9D, such as prohibiting the use of =E2=80=9Csub=E2= =80=9D in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.=C2=A0 Ye= s, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser.=C2=A0 The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key to adoption.=C2=A0 Standards are only useful if they are actually used.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=
=C2=A0
From:=C2=A0Id-event [mailto:id-event-bounces@i= etf.org]=C2=A0On Behalf Of= =C2=A0Richard Backman, Annabelle
Sent:=C2=A0Tuesday, June 13, 2017 5:33 PM
To:= =C2=A0Marius Scurtescu <mscurtescu@googl= e.com>; Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Cc:= =C2=A0ID Events Mailing List <id-event@ietf.org&g= t;
Subject:=C2=A0Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<= /u>
=C2=A0<= /u>
Echoing Marius=E2=80=99s question: can you explain what you mean by =E2=80=9Cinten= d=E2=80=9D?
=C2=A0
To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.
=C2=A0
--=C2=A0
Annabelle Richard Backman=
Identity Services
=C2=A0
=C2=A0
From:=C2=A0Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu@googl= e.com>
Date:=C2= =A0Tuesday, June 13, 2017 at 11:05 AM
To:=C2= =A0Henk Birkholz <henk.bi= rkholz@sit.fraunhofer.de>
Cc:=C2= =A0ID Events Mailing List <id-event@ietf.org&g= t;
Subject:= =C2=A0Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer<= /u>
=C2=A0<= /u>
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.bi= rkholz@sit.fraunhofer.de> wrote:<= /u>
And a 2nd question.

What semantics would "usage= " provide that that are not covered via "intend"= ;, "audience&qu= ot;, and "scope&q= uot;?
=C2=A0<= /u>
"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)=
=C2=A0<= /u>
"scope"= is not used by SET.
=C2=A0<= /u>
I don't know what do you mean by "intend"= ; (or intent)?
=C2=A0<= /u>
=C2=A0<= /u>


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:<= /u>
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2= =80=99t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a =E2=80=9Cfail o= n an unrecognized claim=E2=80=9D approach to ensure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdiff= erent keys for different kinds of JWTs=E2= =80=9D rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2= =80=9D and =E2=80=9Ciss=E2= =80=9D claims.

+1 for a =E2=80=9Ctype=E2= =80=9D or =E2=80=9Cusage=E2= =80=9D claim/header parameter.

--=C2=A0

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bou= nces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@googl= e.com>
*Cc: *Adam Dawes <adawes@google.com= >, "matake, nov= " <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org&g= t;, "Phil Hunt (IDM)" <<= a href=3D"mailto:phil.hunt@oracle.com" style=3D"color:purple;text-decoratio= n:underline" target=3D"_blank">phil.hunt@oracl= e.com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@googl= e.com<mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Tha= nks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The= issue is described by "2.7. Cross-JWT Confusion" a= nd the
=C2=A0 =C2=A0 mit= igation is in "3.9. Use Mutually Exclusive Validation Rules for
=C2=A0 =C2=A0 Dif= ferent Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 req= uired claims...", "Use differe= nt keys for different kinds of
=C2=A0 =C2=A0 JWT= s." and "Use differe= nt issuers for different kinds of JWTs.".

=C2=A0 =C2=A0 I s= till think that a "type" = claim would bring a lot of clarity and
=C2=A0 =C2=A0 saf= ety.


=C2=A0 =C2=A0 Mar= ius

=C2=A0 =C2=A0 On = Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com<= /span>
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com= >> wrote:

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Yaron, Mike and I just published an BCP ID for JWT
=C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <adawes@google.com =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:adawes@google.com>> wrote:

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping SETS to be very similar to
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is a better plan.

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM matake, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nov@matake.jp>= ;> wrote:

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for "type"<= br>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com= <mailto:phil.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +1

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phil


=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <mscur= tescu@google.com
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <mailto:mscurtescu@google.c= om>> wrote:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 distinguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 such a way that naive implementations will not
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 confuse one for the other and open up security
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 vulnerabilities.<= br> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 SET issuer in some cases must be different from the
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 to an IdP.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 following:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> - both "sub&qu= ot; and "iss" t= o be defined at the event
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 level
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> - "iss" a= t event level and at top SET level can
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 be different
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> - "iss" a= nd "sub" a= t event level can be different
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 across events in the same SET
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> - "sub" s= hould NOT be present at the top SET =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 level (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "should" and not "mus= t"
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 define event types to define additional claims
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 related to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 since all these claims will be at the event level
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 there will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 define a composite "aud" c= laim. This is not solving
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 the requirement for a distinct=C2=A0 SE= T issuer. Also,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 having the same claim name having different syntax
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 in different token types could lead to confusion.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 claim for JWTs that defines a "type".= This is not
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 practical in the short term, and it also is not
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 solving the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 this is something the JWT group should seriously
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 consider.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> Thoughts?
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> Marius

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> _________________= ______________________________
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0> Id-event mailing list

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>=C2=A0Id-event@ietf.org=C2=A0<mailto= :Id-event@ie= tf.org>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__w= ww.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKu= gCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_<= wbr>jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd= 0mxPQFJLhxWI&e=3D

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 _________________= ______________________________
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Id-event mailing list
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@ietf.org= >
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0https://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________= ______________________________
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0Id-even= t@ietf.org=C2=A0<mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0http= s://www.ietf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager |adawes@google.com=
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-214-2410
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <tel:(650)%20214-2410>

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 _________________= ______________________________
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0&l= t;mailto:Id-= event@ietf.org>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= https://www.ietf.org/mailman/listinfo/id-= event

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 learn about projects I am working on!



--=C2=A0

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
=C2=A0<= /u>
=C2=A0<= /u>
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
=C2=A0<= /u>




_______________________________________________=

Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event<=
/u>
=C2=A0<= /u>
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
=C2=A0<= /div>
=C2=A0
_______________________________________________
Id-event mailing list
Id-event= @ietf.org
htt= ps://www.ietf.org/mailman/listinfo/id-event
=C2=A0



--001a114495b61ae5fa0552dfa6c6-- From nobody Mon Jun 26 10:02:23 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C449E12EB1C for ; Mon, 26 Jun 2017 10:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU94xFBK6EZA for ; Mon, 26 Jun 2017 10:02:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5200112EAE1 for ; Mon, 26 Jun 2017 10:02:05 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5QH1wvV032575 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 17:01:59 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5QH1vmS021799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 17:01:58 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5QH1t6j006370; Mon, 26 Jun 2017 17:01:55 GMT Received: from [192.168.1.25] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jun 2017 10:01:54 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_47FDDAA3-506B-4430-BD42-7FE010FEB577" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Jun 2017 10:01:52 -0700 In-Reply-To: Cc: Justin Richer , "Richard Backman, Annabelle" , Henk Birkholz , Yaron Sheffer , Mike Jones , John Bradley , ID Events Mailing List To: Marius Scurtescu References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:02:17 -0000 --Apple-Mail=_47FDDAA3-506B-4430-BD42-7FE010FEB577 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would prefer a rule where sub and iss are *always* in the same = location. If we have to have all these if-then exceptions that limits use and = increase complexities. IMO - =E2=80=9Csub=E2=80=9D in the top level was designed for a specific = domain of use. While some SET usage can align, that=E2=80=99s not = necessarily a good thing. The alignment further serves to make it harder = to distinguish SETs for access and ID Tokens. I keep coming back to consistency for all SETs as being less complex and = open to wider usage. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 26, 2017, at 9:43 AM, Marius Scurtescu = wrote: >=20 > Justin, in the case when an RP is issuing the SET to send it to an = IdP, a top level sub as you describe it may not be possible. Or maybe I = misunderstand. >=20 > We agree on "iss" I think, in this case it points to the RP. A top = level "sub" though is problematic, The RP in many cases has the opaque = "sub" as issued by the IdP, but this value is globally unique only when = combined with the IdP "iss". >=20 > Not sure why event.aud would be necessary? >=20 > Marius >=20 > On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer > wrote: > Mike, this is not at all what I see for having the "most support". = Instead I'm seeing a lot of call for having "sub" defined clearly in the = event payload only. >=20 > The "sub" of the main body is the subject as known by the issuer of = the SET itself. This might be the same subject that the subject is known = by at the target of the SET. There are many cases where this isn't true, = and so far one exception case where it is, sometimes. We should not be = writing this for the exception. >=20 > But I think there's a pretty clear path forward. The "sub" in the body = of a SET, if it is included, is *ALWAYS* in the context of the "iss" of = the SET. Always, full stop, no exceptions. No global namespaces, no = restrictions on content, no formats -- it's an opaque (to the SET = standard) value in the domain of the issuer of the SET.=20 >=20 > Event payloads, defined in profiles, describe a subject of the event = itself. Importantly, this is the subject as known by the context in = which the event will be *received*, not in which it was *issued*. = Sometimes those are the same, more often (as we're seeing) we can't = guarantee that. We should not depend on that and we should not treat the = exceptional case as the usual, no matter what syntax another group has = come up with.=20 >=20 > So here's the thing. I think the "sub" of an event should be optional, = and ALWAYS in the context of the issuer, and profiles should not places = further constraints on that. Events themselves should be self-contained. = I regret that we didn't make the registration object in RFC7591 more = self-contained, as that's caused implementation and extension issues. I = think events should always have an internal subject/issuer pair, in the = context of where the event is being consumed. We need to define what = iss/sub mean (in a grand sense) inside the event object in this = document, so that different events don't reinvent the same thing over = and over. If a profile wants to leave that out because they don't need = an identifier for the payload, then they can leave it out. If they want = to leave it out because they want to assume there will "always" be an = iss/sub in the root of the SET, then I have a problem with that. The = issuer of the SET can, and probably does, have its own identifier which = can't be assumed to be universal. Proposing a global subject namespace = or format, as has been suggested elsewhere on this list, is ludicrous = and will never fly as it goes against how JWT namespacing for people and = objects has always worked. We should have a clear semantic data = structure that can be extended and used by all of the use cases that = we've adopted. Optimizing at this stage, especially based on one event, = is going to just lead to things being broken and back-patched later on. = But if one spec wants to leave out the iss/sub inside the event? They = can still do that, but I think that's pretty daft. >=20 >=20 >=20 > In summary: >=20 > iss: issuer of the event > sub: subject of the event as known by the issuer of the event > event.sub: subject of the event as known by the recipient of the event > event.iss: context for the subject of the event as known by the = recipient of the event > event.aud: recipient of the event >=20 >=20 > -- Justin >=20 >=20 > On 6/21/2017 7:45 PM, Mike Jones wrote: >> The proposal that I believe has the most support is keeping things as = they are, leaving it up to profiles and applications to define which = claims they use and how they use them. >>=20 >> =20 >>=20 >> It would be fine for some profiles to use the language below. >>=20 >> =20 >>=20 >> =E2=80=93 Mike >>=20 >> From: Phil Hunt >> Sent: Wednesday, June 21, 2017 6:39 PM >> To: Richard Backman, Annabelle >> Cc: Marius Scurtescu ; John Bradley = ; Henk Birkholz = ; Justin Richer = ; Yaron Sheffer ; = Mike Jones ; ID Events Mailing List = >> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>=20 >> =20 >>=20 >> So I understand what is being proposed is: >>=20 >> If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, = and the issuer of the subject is identical to the issuer for the event, = then =E2=80=9Csub=E2=80=9D may be used at the top level. Otherwise, the = subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims = required to uniquely identify the subject MUST be contained in the event = payload. >>=20 >> For example, an ip address of 1.2.3.4 might be represented in a = =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. = =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4" >> A SCIM resource URI of = https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 = might = be identified in the event payload as: = =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a24= 2bd3859c82c4 = =E2=80=9D= >>=20 >> A Connect Logout event from an OP uses the top level sub claim and = depends on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND = the subject. This means that no party may issue logout events on behalf = of the OP. >>=20 >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com = phil.hunt@o= racle.com >>> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle = > wrote: >>>=20 >>> Fair point. If we do not intend to support multiple profiles within = a single SET, then I=E2=80=99m less concerned about leaving sub = semantics up to the profiles. >>> =20 >>> --=20 >>> Annabelle Richard Backman >>> Identity Services >>> =20 >>> =20 >>> From: Marius Scurtescu > >>> Date: Wednesday, June 21, 2017 at 2:58 PM >>> To: "Richard Backman, Annabelle" > >>> Cc: "Phil Hunt (IDM)" >, John Bradley >, Henk Birkholz = >, Justin Richer = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > >>> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>> =20 >>> Example for multiple events within same profile: IdP account is = disabled (because of hijacking), this can lead to two events: >>> 1. "account-disabled" >>> 2. "sessions-revoked" >>>=20 >>> Marius >>> =20 >>> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle = > wrote: >>>> The spec says that the events claim SHOULD NOT be used to express = multiple logical events. If it=E2=80=99s also not used to express events = from different profiles that correspond to the same logical event (e.g. = an OIDC backchannel logout event alongside a hypothetical RISC logout = event), then I=E2=80=99m not sure what use case that leaves for multiple = events in one SET. >>>> =20 >>>> --=20 >>>> Annabelle Richard Backman >>>> Identity Services >>>> =20 >>>> =20 >>>> From: Id-event > on behalf of "Phil Hunt (IDM)" = > >>>> Date: Wednesday, June 21, 2017 at 2:12 PM >>>> To: John Bradley > >>>> Cc: "Richard Backman, Annabelle" >, Henk Birkholz = >, Justin Richer = >, Marius Scurtescu = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > >>>>=20 >>>> Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >>>> =20 >>>> Separate or combined may be evolving. Mike wants to keep the = current backchannel logout very narrowly scoped. He suggested risc = define its own duplicate definitions and meanings.=20 >>>> =20 >>>> That leads me to believe we will have multi-type events in = practice. >>>> =20 >>>> Session cancellation can occur for many reasons. One of the = differentiators we had tried to make was an assumption that user = initiated events would be part of connect. Risk would cover variations = that drive off of risk calculations like password reset.=20 >>>> =20 >>>> There are also signout events at rp's to let the OP know. These are = not commands but notification that a resource session is cancelled. IOW = single sign out not expected.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On Jun 21, 2017, at 1:58 PM, John Bradley > wrote: >>>>=20 >>>>> I thought we decided that we are only allowing set messages form = the same family that agree on top level claims. >>>>> =20 >>>>> Otherwise there can be no top level claims and we are really = defining a alternative format to JWT in some ways. >>>>> =20 >>>>> John B. >>>>> =20 >>>>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle = > wrote: >>>>>> =20 >>>>>> I agree with John that the JWT type confusion problem and the SET = sub problem can and should be discussed separately. The secevents WG is = probably not the right setting to discuss the former. >>>>>> =20 >>>>>> My concern with the sub claim is that two profiles may dictate = conflicting semantics (e.g. Profile A says it=E2=80=99s a phone number, = Profile B says it=E2=80=99s an email address). If these profiles don=E2=80= =99t provide an alternate way to declare subject of their events, then = they cannot be present within the same token. This incompatibility trap = seems like something that could be easily missed by groups profiling = SET. >>>>>> =20 >>>>>> --=20 >>>>>> Annabelle Richard Backman >>>>>> Identity Services >>>>>> =20 >>>>>> =20 >>>>>> From: John Bradley > >>>>>> Date: Wednesday, June 21, 2017 at 1:39 PM >>>>>> To: Yaron Sheffer > >>>>>> Cc: Justin Richer >, = Marius Scurtescu >, = Annabelle Richard >, = Phil Hunt >, Michael = Jones >, ID Events Mailing List = >, Henk Birkholz = > >>>>>> Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer >>>>>> =20 >>>>>> In the envelope typ is a media/mime type. Registering = application/idt+jwt if we register jwt as a structured name sufix. =20 >>>>>> =20 >>>>>> Using the cty is also possible. I need to think about what is = better but we can agree on a convention. >>>>>> =20 >>>>>> Not everything is going to be a set token like not every JWS is a = JWT. >>>>>> =20 >>>>>> If we are going to define processing rules to stop collisions and = confusion around JWT for different purposes, we should just start using = the typ parameter based on the existing spec. >>>>>> =20 >>>>>> In general content sniffing if there is more than one option = eventually gets you into trouble. >>>>>> =20 >>>>>> I am not convinced that forcing there to be no sub at the top = level is a good idea. =20 >>>>>> =20 >>>>>> It is not the way we should differentiate between SET and = id_tokens. >>>>>> =20 >>>>>> If sub is not allowed at the top level people will do non SET JWT = for things where the subject is scoped to the iss of the token. >>>>>> =20 >>>>>> I think defining sub to be part of the event for cases where the = sub is scoped differently from the issuer of the token is fine, but = should not be required for all event types. >>>>>> =20 >>>>>> I think we should solve the confusion issue separately from the = sub issue. >>>>>> =20 >>>>>> Sorry I am at CIS so trying to catch up on lists. >>>>>> =20 >>>>>> John B. >>>>>> =20 >>>>>>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer = > wrote: >>>>>>> =20 >>>>>>> So to summarize what I'm seeing on this thread: >>>>>>> Everybody agrees with Marius's short-term solution, specific = rules for "sub" and "iss" that can be defined in the SET spec. >>>>>>> Almost everybody agrees on a long-term "usage" claim ("type" is = taken) that should be defined elsewhere, e.g. in the JWT BCP. >>>>>>> Did I miss anything? >>>>>>> By the way, if we do add a "usage" claim, we need to also use it = in the SET document before it is published. >>>>>>> Thanks, >>>>>>> Yaron >>>>>>> =20 >>>>>>> On 15/06/17 22:08, Justin Richer wrote: >>>>>>>> +1 to this as well.=20 >>>>>>>> =20 >>>>>>>> =E2=80=94 Justin >>>>>>>> =20 >>>>>>>>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu = > wrote: >>>>>>>>> =20 >>>>>>>>> +1 to what Annabelle said.=20 >>>>>>>>> =20 >>>>>>>>> Also, Mike you are missing the other requirement, for RPs to = send events to an IdP. The iss+sub pair at the top level is broken in = this case. >>>>>>>>>=20 >>>>>>>>> Marius >>>>>>>>> =20 >>>>>>>>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) = > wrote: >>>>>>>>>> +1 >>>>>>>>>> =20 >>>>>>>>>> Phil >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: >>>>>>>>>>> Mike, >>>>>>>>>>> =20 >>>>>>>>>>> Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with it: >>>>>>>>>>> 1. The caller of the Token Endpoint is the only party = that can be certain that a nonce-less ID Token is really an ID Token. = Any party that the caller passes the ID Token off to has no way to = verify its provenance. >>>>>>>>>>>=20 >>>>>>>>>>> 2. Any future ID Token distribution method needs to = solve this problem again. >>>>>>>>>>>=20 >>>>>>>>>>> 3. No other profile of JWT can ever use the "nonce=E2=80=9D= claim. >>>>>>>>>>>=20 >>>>>>>>>>> 4. This is only a solution for ID Tokens. Every other = JWT profile that cares about disambiguation has to invent its own = solution to the problem. >>>>>>>>>>>=20 >>>>>>>>>>> =20 >>>>>>>>>>> We know from experience that naming collisions and replay = attacks are both things that happen. What=E2=80=99s being proposed is a = simple, defensive measure against these risks. You brought up JWT = libraries: a general solution actually makes it easier to use common = libraries for JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library = could handle disambiguation for any JWT profile, whereas with the status = quo each profile would require unique logic. >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> From: Id-event > on behalf of Mike Jones = > >>>>>>>>>>> Date: Wednesday, June 14, 2017 at 1:16 PM >>>>>>>>>>> To: Marius Scurtescu > >>>>>>>>>>> Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > >>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer >>>>>>>>>>> =20 >>>>>>>>>>> You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D= . I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprema= ture pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. >>>>>>>>>>> =20 >>>>>>>>>>> Mandatory solutions are being proposed in this thread to = problems that there=E2=80=99s no evidence that we actually even have. = It=E2=80=99s already been established that it=E2=80=99s impossible for a = SET to be confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. >>>>>>>>>>> =20 >>>>>>>>>>> The proposed =E2=80=9Csolutions=E2=80=9D, such as = prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, or = requiring a type claim, would make previously simple things = unnecessarily complex. Yes, then the result is then different than a = normal JWT but a consequence of this is that custom parsing code would = have to be used, rather than a standard JWT parser. The more unwieldy = we make it to use SETs, the more likely developers are to just create = their own data structures. Keeping it simple is the key to adoption. = Standards are only useful if they are actually used. >>>>>>>>>>> =20 >>>>>>>>>>> -- Mike >>>>>>>>>>> =20 >>>>>>>>>>> From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle >>>>>>>>>>> Sent: Tuesday, June 13, 2017 5:33 PM >>>>>>>>>>> To: Marius Scurtescu >; Henk Birkholz = > >>>>>>>>>>> Cc: ID Events Mailing List > >>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer >>>>>>>>>>> =20 >>>>>>>>>>> Echoing Marius=E2=80=99s question: can you explain what you = mean by =E2=80=9Cintend=E2=80=9D? >>>>>>>>>>> =20 >>>>>>>>>>> To your first question, I think a better analogy would be = the X.509 Key Usage extension: a multi-valued property that declares the = intended purpose of the JWT, and that a recipient may refer to when = determining whether to accept a JWT being presented to it in some = context. >>>>>>>>>>> =20 >>>>>>>>>>> --=20 >>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>> Identity Services >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>> From: Id-event > on behalf of Marius Scurtescu = > >>>>>>>>>>> Date: Tuesday, June 13, 2017 at 11:05 AM >>>>>>>>>>> To: Henk Birkholz > >>>>>>>>>>> Cc: ID Events Mailing List > >>>>>>>>>>> Subject: Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer >>>>>>>>>>> =20 >>>>>>>>>>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: >>>>>>>>>>>> And a 2nd question. >>>>>>>>>>>>=20 >>>>>>>>>>>> What semantics would "usage" provide that that are not = covered via "intend", "audience", and "scope"? >>>>>>>>>>> =20 >>>>>>>>>>> "aud" (audience) specifies the target client, but not the = intended usage (access token to authorize resource access or SET to = communicate a security event?) >>>>>>>>>>> =20 >>>>>>>>>>> "scope" is not used by SET. >>>>>>>>>>> =20 >>>>>>>>>>> I don't know what do you mean by "intend" (or intent)? >>>>>>>>>>> =20 >>>>>>>>>>> =20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Henk >>>>>>>>>>>>=20 >>>>>>>>>>>> On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: >>>>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I think the assumptions inherent in 3.9 are flawed: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =C2=B7We can=E2=80=99t guarantee that every type of JWT = will have a mutually exclusive set of valid claims and/or header = parameters, and enforcing this requires a =E2=80=9Cfail on an = unrecognized claim=E2=80=9D approach to ensure that JWTs from some = future spec can=E2=80=99t be mistaken for JWTs from a current spec. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =C2=B7It is unrealistic to expect implementers to adhere = to the =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D = rule. Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80= =9D claims. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Annabelle Richard Backman >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Identity Services >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *From: *Id-event > on behalf of Dick Hardt = > >>>>>>>>>>>>> *Date: *Monday, June 12, 2017 at 3:18 PM >>>>>>>>>>>>> *To: *Marius Scurtescu > >>>>>>>>>>>>> *Cc: *Adam Dawes >, "matake, nov" >, ID Events Mailing List >, "Phil Hunt (IDM)" > >>>>>>>>>>>>> *Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Agreed. Note that there is still lots of discussion on = what should be in 3.9. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = >> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks for the pointer Dick, very good timing :-) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The issue is described by "2.7. Cross-JWT Confusion" = and the >>>>>>>>>>>>> mitigation is in "3.9. Use Mutually Exclusive = Validation Rules for >>>>>>>>>>>>> Different Kinds of JWTs", specifically "Use different = sets of >>>>>>>>>>>>> required claims...", "Use different keys for different = kinds of >>>>>>>>>>>>> JWTs." and "Use different issuers for different kinds = of JWTs.". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I still think that a "type" claim would bring a lot of = clarity and >>>>>>>>>>>>> safety. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Marius >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt = >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yaron, Mike and I just published an BCP ID for JWT >>>>>>>>>>>>> http://self-issued.info/?p=3D1690 = >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes = >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I was initially a fan of keeping SETS to be = very similar to >>>>>>>>>>>>> id tokens but I now think this is a better = plan. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Jun 8, 2017 at 6:56 PM matake, nov = >>>>>>>>>>>>> >> = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 especially for "type" >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) >>>>>>>>>>>>> >>: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> > On Jun 8, 2017, at 6:28 PM, Marius = Scurtescu >>>>>>>>>>>>> >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > There were a couple of proposals on = how to >>>>>>>>>>>>> distinguish SETs from Id Tokens and = Access Tokens in >>>>>>>>>>>>> such a way that naive implementations = will not >>>>>>>>>>>>> confuse one for the other and open up = security >>>>>>>>>>>>> vulnerabilities. >>>>>>>>>>>>> > >>>>>>>>>>>>> > There is also another important = requirement: the >>>>>>>>>>>>> SET issuer in some cases must be = different from the >>>>>>>>>>>>> "sub" issuer. This is the case of an = RP sending SETs >>>>>>>>>>>>> to an IdP. >>>>>>>>>>>>> > >>>>>>>>>>>>> > With these requirements in mind I = propose the >>>>>>>>>>>>> following: >>>>>>>>>>>>> > - both "sub" and "iss" to be = defined at the event >>>>>>>>>>>>> level >>>>>>>>>>>>> > - "iss" at event level and at top = SET level can >>>>>>>>>>>>> be different >>>>>>>>>>>>> > - "iss" and "sub" at event level = can be different >>>>>>>>>>>>> across events in the same SET >>>>>>>>>>>>> > - "sub" should NOT be present at = the top SET >>>>>>>>>>>>> level (this solves the = disambiguation), please note >>>>>>>>>>>>> "should" and not "must" >>>>>>>>>>>>> > >>>>>>>>>>>>> > This solution also allows different = profiles that >>>>>>>>>>>>> define event types to define = additional claims >>>>>>>>>>>>> related to sub (like email or = phone_number) and >>>>>>>>>>>>> since all these claims will be at the = event level >>>>>>>>>>>>> there will be no collisions or = ambiguity. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Another proposal (which I = supported) was to >>>>>>>>>>>>> define a composite "aud" claim. This = is not solving >>>>>>>>>>>>> the requirement for a distinct SET = issuer. Also, >>>>>>>>>>>>> having the same claim name having = different syntax >>>>>>>>>>>>> in different token types could lead to = confusion. >>>>>>>>>>>>> > >>>>>>>>>>>>> > And yet another proposal was to = introduce a new >>>>>>>>>>>>> claim for JWTs that defines a "type". = This is not >>>>>>>>>>>>> practical in the short term, and it = also is not >>>>>>>>>>>>> solving the distinct issuer = requirement, but I think >>>>>>>>>>>>> this is something the JWT group should = seriously >>>>>>>>>>>>> consider. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thoughts? >>>>>>>>>>>>> > >>>>>>>>>>>>> > Marius >>>>>>>>>>>>>=20 >>>>>>>>>>>>> > = _______________________________________________ >>>>>>>>>>>>> > Id-event mailing list >>>>>>>>>>>>> > Id-event@ietf.org = > >>>>>>>>>>>>> > >>>>>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>>>>> = https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>>>>> = https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Adam Dawes | Sr. Product Manager = |adawes@google.com >>>>>>>>>>>>> > |+1 650-214-2410 >>>>>>>>>>>>> > >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org = > >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Subscribe to the HARDTWARE > mail list to >>>>>>>>>>>>> learn about projects I am working on! >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>>>>> =20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = >>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>>>> =20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Id-event mailing list >>>>>>>> Id-event@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/id-event = =20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/id-event = >>>>>> =20 >>>>>=20 >>>>> =20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event = >>> =20 >>=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D5nEWLHNlT6T5AGT= IYqLOHQWDsyMU6aBF12pECG2xhHM&s=3DG9H4qR9aSCbjpURD9Ear_fgjhUkH_n-3V1CZMkIOc= _8&e=3D = --Apple-Mail=_47FDDAA3-506B-4430-BD42-7FE010FEB577 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I would prefer a rule where sub and iss are *always* in the = same location.

If we = have to have all these if-then exceptions that limits use and increase = complexities.

IMO - =E2=80=9Csub=E2=80=9D in the top level was designed for = a specific domain of use.  While some SET usage can align, that=E2=80= =99s not necessarily a good thing. The alignment further serves to make = it harder to distinguish SETs for access and ID Tokens.

I keep coming back to = consistency for all SETs as being less complex and open to wider = usage.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 26, 2017, at 9:43 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

Justin, in the case when an RP is issuing the SET to send it = to an IdP, a top level sub as you describe it may not be possible. Or = maybe I misunderstand.

We agree on "iss" I think, in this case it points to the RP. = A top level "sub" though is problematic, The RP in many cases has the = opaque "sub" as issued by the IdP, but this value is globally unique = only when combined with the IdP "iss".

Not sure why event.aud would be = necessary?

Marius

On Sun, Jun 25, 2017 at 7:31 AM, Justin = Richer <jricher@mit.edu> wrote:

Mike, this = is not at all what I see for having the "most support". Instead I'm = seeing a lot of call for having "sub" defined clearly in the event = payload only.

The "sub" of the main body = is the subject as known by the issuer of the SET itself. This might be = the same subject that the subject is known by at the target of the SET. = There are many cases where this isn't true, and so far one exception = case where it is, sometimes. We should not be writing this for the = exception.

But I think there's a pretty clear path = forward. The "sub" in the body of a SET, if it is included, is *ALWAYS* = in the context of the "iss" of the SET. Always, full stop, no = exceptions. No global namespaces, no restrictions on content, no formats = -- it's an opaque (to the SET standard) value in the domain of the = issuer of the SET. 

Event payloads, defined in profiles, = describe a subject of the event itself. Importantly, this is the subject = as known by the context in which the event will be *received*, not in = which it was *issued*. Sometimes those are the same, more often (as = we're seeing) we can't guarantee that. We should not depend on that and = we should not treat the exceptional case as the usual, no matter what = syntax another group has come up with. 

So here's the thing. I think the "sub" of an event should be = optional, and ALWAYS in the context of the issuer, and profiles should = not places further constraints on that. Events themselves should be = self-contained. I regret that we didn't make the registration object in = RFC7591 more self-contained, as that's caused implementation and = extension issues. I think events should always have an internal = subject/issuer pair, in the context of where the event is being = consumed. We need to define what iss/sub mean (in a grand sense) inside = the event object in this document, so that different events don't = reinvent the same thing over and over. If a profile wants to leave that = out because they don't need an identifier for the payload, then they can = leave it out. If they want to leave it out because they want to assume = there will "always" be an iss/sub in the root of the SET, then I have a = problem with that. The issuer of the SET can, and probably does, have = its own identifier which can't be assumed to be universal. Proposing a = global subject namespace or format, as has been suggested elsewhere on = this list, is ludicrous and will never fly as it goes against how JWT = namespacing for people and objects has always worked. We should have a = clear semantic data structure that can be extended and used by all of = the use cases that we've adopted. Optimizing at this stage, especially = based on one event, is going to just lead to things being broken and = back-patched later on. But if one spec wants to leave out the iss/sub = inside the event? They can still do that, but I think that's pretty = daft.


In = summary:

  • iss: issuer of the = event
  • sub: subject of the event as known by the = issuer of the event
  • event.sub: subject of the event = as known by the recipient of the event
  • event.iss: context for the subject of the event as known by = the recipient of the event
  • event.aud: recipient of = the event


 --= Justin


On 6/21/2017 7:45 PM, = Mike Jones wrote:

The proposal that I believe has the most support is = keeping things as they are, leaving it up to profiles and applications = to define which claims they use and how they use them.

 

It would be fine for some profiles to use the = language below.

 

=E2=80=93 Mike

From: Phil = Hunt
Sent: Wednesday, June 21, = 2017 6:39 PM
To: Richard = Backman, Annabelle
Cc: Marius = Scurtescu; John = Bradley; Henk Birkholz; Justin = Richer; Yaron = Sheffer; Mike Jones; ID Events = Mailing List
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer

 

So I understand = what is being proposed is:

If the event type uses = =E2=80=9Csub=E2=80=9D to identify its subject, and the issuer of the = subject is identical to the issuer for the event, then =E2=80=9Csub=E2=80=9D= may be used at the top level. Otherwise, the subject of an event (e.g. = =E2=80=9Csub=E2=80=9D) and any other claims required to uniquely = identify the subject MUST be contained in the event = payload.

For example, an ip address of 1.2.3.4 might be represented in = a =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. = =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"
A = SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might = be identified in the event payload as: =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=E2=80=9D

A Connect Logout event from an OP uses the top level sub = claim and depends on =E2=80=9Ciss=E2=80=9D being the same for the event = issuer AND the subject. This means that no party may issue logout events = on behalf of the OP.


Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun = 21, 2017, at 3:38 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

Fair point. If we do not = intend to support multiple profiles within a single SET, then I=E2=80=99m = less concerned about leaving sub semantics up to the profiles.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: = Marius = Scurtescu <mscurtescu@google.com>
Date: Wed= nesday, June 21, 2017 at 2:58 PM
To: "Ri= chard Backman, Annabelle" <richanna@amazon.com>
Cc: "Ph= il Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley = <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, = Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>
Subject: Re:= [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Example for multiple events within same = profile: IdP account is disabled (because of hijacking), this can lead = to two events:
1. = "account-disabled"
2. = "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
The spec says that the events claim SHOULD NOT = be used to express multiple logical events. If it=E2=80=99s also not = used to express events from different profiles that correspond to the = same logical event (e.g. an OIDC backchannel logout event alongside a = hypothetical RISC logout event), then I=E2=80=99m not sure what use case = that leaves for multiple events in one SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: = Id-event = <id-event-bounces@ietf.org> on behalf of "Phil Hunt = (IDM)" <phil.hunt@oracle.com>
Date: Wed= nesday, June 21, 2017 at 2:12 PM
To: Joh= n Bradley <ve7jtb@ve7jtb.com>
Cc: "Ri= chard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, = Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>

Subject: Re:= [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Separate or combined may be evolving. Mike wants to keep the = current backchannel logout very narrowly scoped. He suggested risc = define its own duplicate definitions and meanings. 
 
That leads me to believe we will have = multi-type events in practice.
 
Session cancellation can occur for many = reasons. One of the differentiators we had tried to make was an = assumption that user initiated events would be part of connect. Risk = would cover variations that drive off of risk calculations like password = reset. 
 
There are also signout events at rp's to let = the OP know. These are not commands but notification that a resource = session is cancelled. IOW single sign out not expected. 

Phil


On Jun 21, 2017, at 1:58 PM, John Bradley = <ve7jtb@ve7jtb.com>= wrote:

I = thought we decided that we are only allowing set messages form the same = family that agree on top level claims.
 
Otherwise there can = be no top level claims and we are really defining a alternative format = to JWT in some ways.
 
John B.
 
On Jun = 21, 2017, at 3:54 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
 
I agree with John = that the JWT type confusion problem and the SET sub problem can and = should be discussed separately. The secevents WG is probably not the = right setting to discuss the former.
 
My= concern with the sub claim is that two profiles may dictate conflicting = semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B = says it=E2=80=99s an email address). If these profiles don=E2=80=99t = provide an alternate way to declare subject of their events, then they = cannot be present within the same token. This incompatibility trap seems = like something that could be easily missed by groups profiling = SET.
 
-- 
Annabelle Richard Backman
Identity = Services
 
 
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
In the envelope typ is a = media/mime type.  Registering application/idt+jwt if we register = jwt as a structured name sufix.  
 
Using the cty is also possible.   I need to think about = what is better but we can agree on a convention.
 
Not everything is going to be a set token like not every JWS = is a JWT.
 
If we are going to define processing rules to stop collisions = and confusion around JWT for different purposes, we should just start = using the typ parameter based on the existing spec.
 
In general content sniffing if there is more than one option = eventually gets you into trouble.
 
I am not convinced that forcing there to be no sub at the top = level is a good idea.  
 
It is not the way we should differentiate between SET and = id_tokens.
 
If sub is not = allowed at the top level people will do non SET JWT for things where the = subject is scoped to the iss of the token.
 
I think defining sub to be part of the event for cases where = the sub is scoped differently from the issuer of the token is fine, but = should not be required for all event types.
 
I think we should solve the confusion issue separately from = the sub issue.
 
Sorry I am at = CIS so trying to catch up on lists.
 
John B.
 
On Jun 17, = 2017, at 3:45 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
So to = summarize what I'm seeing on this thread:
Everybody = agrees with Marius's short-term solution, specific rules for "sub" and = "iss" that can be defined in the SET spec.
Almost = everybody agrees on a long-term "usage" claim ("type" is taken) that = should be defined elsewhere, e.g. in the JWT BCP.
Did I miss = anything?
By the way, if we do add a "usage" claim, we = need to also use it in the SET document before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, Justin Richer wrote:
+1 to this as well. 
 
 =E2=80=94 Justin
 
On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what = Annabelle said. 
 
Also, Mike you are missing the other requirement, for RPs to = send events to an IdP. The iss+sub pair at the top level is broken in = this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1
 
Phil

 

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = <richanna@amazon.com> = wrote:
Mike,
 
Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the = only party that can be certain that a nonce-less ID Token is really an = ID Token. Any party that the caller passes the ID Token off to has no = way to verify its provenance.

2.       Any future ID Token distribution method = needs to solve this problem again.

3.      No other profile of JWT can ever use = the "nonce=E2=80=9D claim.

4.      This is only a solution for ID Tokens. = Every other JWT profile that cares about disambiguation has to invent = its own solution to the problem.

 
We= know from experience that naming collisions and replay attacks are both = things that happen. What=E2=80=99s being proposed is a simple, defensive = measure against these risks. You brought up JWT libraries: a general = solution actually makes it easier to use common libraries for JWT = parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity = Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Mike = Jones <Michael.Jones@microsoft.com>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <mscurtescu@google.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events = Mailing List <id-event@ietf.org>, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
You=E2=80=99ve heard of =E2=80=9Cpremature = optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in = this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making = things that can and should be simple complex, without data showing = there=E2=80=99s any need to do so.
 
Mandatory solutions are being proposed in this thread to = problems that there=E2=80=99s no evidence that we actually even = have.  It=E2=80=99s already been established that it=E2=80=99s = impossible for a SET to be confused for an ID Token =E2=80=93 see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing = that this is possible with specific kinds of Access Tokens or other real = JWT deployments, please provide specifics, so that we can use that data = to inform appropriate engineering choices on our part.
 
The proposed =E2=80=9Csolutions=E2=80=9D, = such as prohibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, = or requiring a type claim, would make previously simple things = unnecessarily complex.  Yes, then the result is then different than = a normal JWT but a consequence of this is that custom parsing code would = have to be used, rather than a standard JWT parser.  The more = unwieldy we make it to use SETs, the more likely developers are to just = create their own data structures.  Keeping it simple is the key to = adoption.  Standards are only useful if they are actually = used.
 
          &nb= sp;            = ;                 &nb= sp;       -- Mike
 
From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz = <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer
 
Echoing Marius=E2=80=99s question: can you explain what you = mean by =E2=80=9Cintend=E2=80=9D?
 
To= your first question, I think a better analogy would be the X.509 Key = Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context.
 
-- 
Annabelle Richard Backman
Identity = Services
 
 
From: Id-event <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
On Tue, Jun = 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd = question.

What semantics would "usage" = provide that that are not covered via "intend", "audience", and = "scope"?
 
"aud" (audience) specifies = the target client, but not the intended usage (access token to authorize = resource access or SET to communicate a security event?)
 
"scope" is not used by SET.
 
I don't know what do you mean by "intend" (or = intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, = Annabelle wrote:
Thanks = for putting this together!

I think the = assumptions inherent in 3.9 are flawed:

=C2=B7= We can=E2=80=99t guarantee that every type of JWT will have a mutually = exclusive set of valid claims and/or header parameters, and enforcing = this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach = to ensure that JWTs from some future spec can=E2=80=99t be mistaken for = JWTs from a current spec.

=C2=B7It is = unrealistic to expect implementers to adhere to the =E2=80=9Cdifferent = keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by the = spec or not, implementers will ignore this because managing one key is = easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D= claims.

+1 for a =E2=80=9Ctype=E2=80=9D or = =E2=80=9Cusage=E2=80=9D claim/header parameter.

-- 

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick = Hardt <dick.hardt@gmail.com>*Date: *Monday, June 12, 2017 at 3:18 PM
*To: = *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam = Dawes <adawes@google.com>, = "matake, nov" <nov@matake.jp>, ID = Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

Agreed. = Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius = Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer = Dick, very good timing :-)

  =   The issue is = described by "2.7. Cross-JWT Confusion" and the
  =   mitigation is = in "3.9. Use Mutually Exclusive Validation Rules for
  =   Different Kinds = of JWTs", specifically "Use different sets of
  =   required = claims...", "Use different keys for different kinds of
    JWTs." and "Use different = issuers for different kinds of JWTs.".

 =   I still think = that a "type" claim would bring a lot of clarity and
  =   safety.


    Marius

    On Thu, Jun 8, 2017 at 9:59 = PM, Dick Hardt <dick.hardt@gmail.com
  =   <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I just = published an BCP ID for JWT
      =   http://self-issued.info/?p=3D1690
        On Thu, Jun 8, 2017 at 9:02 = PM Adam Dawes <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I was initially a fan of = keeping SETS to be very similar to
      =       id = tokens but I now think this is a better plan.

            On Thu, Jun 8, 2017 at 6:56 = PM matake, nov <nov@matake.jp
            <mailto:nov@matake.jp>> wrote:

                +1 especially for "type"

            =     2017-06-09= 10:32 GMT+09:00 Phil Hunt (IDM)
      =           <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

                =     +1

            =         Phil


            =          > On Jun 8, 2017, at 6:28 PM, = Marius Scurtescu
            =         <mscurtescu@google.com
            =         <mailto:mscurtescu@google.com>> wrote:
          =            >
  =                   =  > There were a couple of proposals on how to
 =                   distinguish SETs from Id = Tokens and Access Tokens in
        =             such a way that naive = implementations will not
        =             confuse one for the other = and open up security
          =           vulnerabilities.
                =      >
        =              > There is also = another important requirement: the
      =               SET issuer in some cases = must be different from the
        =             "sub" issuer. This is the = case of an RP sending SETs
        =             to an IdP.
                =      >
        =              > With these = requirements in mind I propose the
      =               following:
                =      > - both "sub" and "iss" to be defined at the = event
              =       level
  =                   =  > - "iss" at event level and at top SET level can
                =     be = different
              =        > - "iss" and "sub" at event level can be = different
              =       across events in the same = SET
              =        > - "sub" should NOT be present at the top = SET
              =       level (this solves the = disambiguation), please note
        =             "should" and not "must"
                =      >
        =              > This solution also = allows different profiles that
        =             define event types to = define additional claims
        =             related to sub (like email = or phone_number) and
          =           since all these claims will = be at the event level
          =           there will be no collisions = or ambiguity.
            =          >
    =                  > = Another proposal (which I supported) was to
    =                 define a composite "aud" = claim. This is not solving
        =             the requirement for a = distinct  SET issuer. Also,
      =               having the same claim name = having different syntax
          =           in different token types = could lead to confusion.
        =              >
  =                   =  > And yet another proposal was to introduce a new
                =     claim = for JWTs that defines a "type". This is not
    =                 practical in the short = term, and it also is not
        =             solving the distinct issuer = requirement, but I think
        =             this is something the JWT = group should seriously
          =           consider.
                =      >
        =              > Thoughts?
                =      >
        =              > Marius

            =          > = _______________________________________________
                =      > Id-event mailing list

  =                   =  > Id-event@ietf.org <mailto:Id-event@ietf.org>
    =                  >
                =     https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                =     _____________________________= __________________
      =               Id-event mailing list
                =     Id-event@ietf.org <mailto:Id-event@ietf.org>
    =                 https://www.ietf.org/mailman/listinfo/id-event

                _____________________________= __________________
      =           Id-event mailing list
                Id-event@ietf.org <mailto:Id-event@ietf.org>
    =             https://www.ietf.org/mailman/listinfo/id-event

            -- 
          =   Adam Dawes | = Sr. Product Manager |adawes@google.com
    =         <mailto:adawes@google.com> |+1 650-214-2410
  =           <tel:(650)%20214-2410>

            _____________________________= __________________
      =       Id-event mailing list
            Id-event@ietf.org <mailto:Id-event@ietf.org>
    =         https://www.ietf.org/mailman/listinfo/id-event

        -- 
        Subscribe to the HARDTWARE = <http://hardtware.com/> mail list to
        learn about projects I am = working on!



-- 

Subscribe to the HARDTWARE = <http://hardtware.com/> mail list to learn about = projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 




_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3D5nEWLHNlT6T5AGTIYqLOHQWDsyMU6aBF12pECG2xhHM&s=3DG9H4qR9aSC= bjpURD9Ear_fgjhUkH_n-3V1CZMkIOc_8&e=3D
= --Apple-Mail=_47FDDAA3-506B-4430-BD42-7FE010FEB577-- From nobody Mon Jun 26 10:05:39 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0712EAE1 for ; Mon, 26 Jun 2017 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfQF5uNUCTmq for ; Mon, 26 Jun 2017 10:05:30 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0090.outbound.protection.outlook.com [104.47.38.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75755129B7A for ; Mon, 26 Jun 2017 10:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7ZTQuEVGJJMXD4MHu8rpMnihg4iOBpuFFUd8l9zFDNE=; b=WKZQT2ixvbBRBqGQw3R1k4adXu1RDOweZZdlOm0p29UNLBi9SG1GXrcl5e3U6SsiWBk7PaVk8a8j0jlB6LVYXxvWNMzm/YW9w1tx+6cVqlNgdVcgwieCB9lb3zqoBjSxHVL+f+H+Hfq2dLwWU0qbBfhTJigdXEAklujV2tKeVVw= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0472.namprd21.prod.outlook.com (10.172.121.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.2; Mon, 26 Jun 2017 17:05:25 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.008; Mon, 26 Jun 2017 17:05:25 +0000 From: Mike Jones To: Justin Richer , Marius Scurtescu CC: Phil Hunt , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Yaron Sheffer , "ID Events Mailing List" Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAZHxQCAAAQVgIAAAU6AgAAD8YCAAAu+gIAAARyAgAAK8YCAABEWAIAAAeGLgAWuUgCAAbcqAIAAANpg Date: Mon, 26 Jun 2017 17:05:25 +0000 Message-ID: References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-26T10:05:23.0254691-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0472; 7:7E/At86ZvN3zRGaHCAQ3R68RabW280jWD/2bqmMCxSg1gSNaBfLasHRWckGe+1bvun4rpk00Tv7hIwmKLi4WDQwpbqjX9FlVwTpk/dRhglDVBTcPK2vrZrWoOfwDhebge7vD7lNB20q1Fk04jurKrJXxykg2dOnZqLEmYBN3Vzl5n1iEdgjp6eJGgfd5Zik6Nc7VfOYeSoeO8EWTYb6vRIGbp9Vly2s5x2vKuJybDcXKNWkvmr1nop/663qqNqOYutRwnVyUZKzZnCWCrMTghqmVARawEqVI5S6OZiSOuLAhojUBeXOqxZQPnK8rA7gbMbIQNIEzBn5fIp27lRS6iOo0bRtO2skqglBIDF3lSAuuMcEz7vkGBNUFCXgvbGHuPvgAzCvq3TKMj7oose7vS9HQ49kFlmVHh56kHmY5jhcSonOM1hPi66QP/c0UO8t7dpIdHDJT6idnRbaL17I/fpGFPcFfsrPUqS/UoVkbpwWPrQuLRdScPvNdfvXFjCpVq2kiKengnym6jvHMV0uGJnVBvz2QEWvYO/Z2/B7CRK0gVxO6cT4DoZwukDu8hRv7jVIT/maoAn/iVS6XbBLPYZc78UFpm8r5++i0yO0p/fp0x30Y1rDymFcMqYb+ZWry44B44vgGtXOlIgLq2w8RVFKe7dUZ7PNArJJYVWluGIKWgM1M5hARs6QmFEbhH24YWCpPuwOHMUfNeRNttstVxuTtB0Fy+Bkb7cRQVfBHvmj4e9g5Plh5HnWZsEVZorSHMrL0fYaaLkn/N7kDdgJsi6PHksK/S4wItPRjmDlsIZ3x2e0Mu2TvC6b8rabIownS x-ms-office365-filtering-correlation-id: ac31d788-0b4b-4844-1591-08d4bcb58a04 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:CY4PR21MB0472; x-ms-traffictypediagnostic: CY4PR21MB0472: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(133145235818549)(278428928389397)(26388249023172)(236129657087228)(192374486261705)(131327999870524)(90097320859284)(48057245064654); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0472; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0472; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(39860400002)(209900001)(377454003)(51444003)(51914003)(24454002)(377424004)(551544002)(6246003)(86362001)(38730400002)(575784001)(93886004)(33656002)(53386004)(2900100001)(86612001)(561944003)(10090500001)(74316002)(7906003)(122556002)(2950100002)(8990500004)(229853002)(76176999)(53376002)(54356999)(5005710100001)(50986999)(3660700001)(54906002)(39060400002)(6306002)(55016002)(2906002)(99286003)(53546010)(9686003)(7520500002)(236005)(54896002)(6436002)(16200700003)(478600001)(19609705001)(189998001)(81166006)(8676002)(25786009)(8936002)(606005)(790700001)(102836003)(72206003)(53936002)(5660300001)(3280700002)(10290500003)(14454004)(6116002)(4326008)(77096006)(7736002)(6506006)(2171002)(53946003)(7696004)(966005)(7066003)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0472; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05045836B0610DDAD95B0039F5DF0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 17:05:25.4726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0472 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:05:38 -0000 --_000_CY4PR21MB05045836B0610DDAD95B0039F5DF0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLA0KDQpUaGUgcnVsZXMgeW914oCZcmUgcHJvcG9zaW5nIG1heSBiZSBmaW5lIGZvciBh IFNFVCBwcm9maWxlIGZvciBhIHBhcnRpY3VsYXIga2luZCBvZiBhcHBsaWNhdGlvbi4gIEkgZW5j b3VyYWdlIHlvdSB0byBqb2luIHRoZSBSSVNDIHdvcmtpbmcgZ3JvdXAgYW5kIHdvcmsgb24gdGhl bSB0aGVyZS4gIEJ1dCB0aGV5IHdvdWxkIGxpbWl0IHRoZSB1c2UgY2FzZXMgdGhhdCBTRVRzIGNv dWxkIGJlIHVzZWQgZm9yLCB3aGljaCB3b3VsZCBiZSB1bmZvcnR1bmF0ZSBhbmQgdW5uZWNlc3Nh cnkuDQoNCkFuIGFuYWxvZ3kgd2l0aCBKV1QgaXMgaWxsdXN0cmF0aXZlLiAgSldUIGlzIGludGVu dGlvbmFsbHkgZ2VuZXJhbC1wdXJwb3NlLCBsZWF2aW5nIGl0IHVwIHRvIGFwcGxpY2F0aW9uIHBy b2ZpbGVzIHdoYXQgY2xhaW1zIHRvIHVzZSBhbmQgd2hhdCB0aGVpciBzZW1hbnRpY3MgYXJlLiAg VGhpcyBlbmFibGVzIEpXVHMgdG8gYmUgdXNlZCBmb3IgSUQgVG9rZW5zPGh0dHA6Ly9vcGVuaWQu bmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUtMV8wLmh0bWwjSURUb2tlbj4gYW5kIGFsc28g Zm9yIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHVzZXMsIHN1Y2ggYXMgU0lQPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MDU1PiBhbmQgQ2FsbGVyIElEPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtMTE+LiAgVGhlcmUgaXMgbm8gZXhwZWN0 YXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHRoZXNlIGRpZmZlcmVudCBKV1QgYXBw bGljYXRpb25zLiAgSW5kZWVkIOKAkyBib3RoIHRoZSBzeW50YXggKmFuZCB0aGUgc2VtYW50aWNz Kiwgc3VjaCBoYXMgaG93IHRvIGRldGVybWluZSB3aGF0IGtleXMgYXJlIHZhbGlkLCBhcmUgZGlm ZmVyZW50LiAgSXTigJlzIHRoaXMgZmxleGliaWxpdHkgdGhhdCBtYWtlcyBKV1RzIGdlbmVyYWwt cHVycG9zZS4NCg0KTGlrZXdpc2UsIFNFVCBhcyBjdXJyZW50bHkgc3BlY2lmaWVkIGlzIHNpbWls YXJseSBnZW5lcmFsLXB1cnBvc2UuICBBcHBsaWNhdGlvbiBwcm9maWxlcyBkZWZpbmUgd2hhdCBT RVQgY2xhaW1zIHRvIHVzZSBhbmQgdGhlaXIgc2VtYW50aWNzLiAgVGhlcmUgaXMgbm8gZXhwZWN0 YXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBTRVQgcHJvZmlsZXMs IG5vciBzaG91bGQgdGhlcmUgYmUsIGFzIHRoZWlyIGFwcGxpY2F0aW9ucyBhcmUgZGlmZmVyZW50 LiAgVHJ5aW5nIHRvIG1ha2UgU0VUcyByZXF1aXJlIGNob2ljZXMgYXBwcm9wcmlhdGUgdG8gYSBw YXJ0aWN1bGFyIHByb2ZpbGUgd2lsbCBuZWNlc3NhcmlseSBtYWtlIHRoZW0gYSBwb29yIG9yIGlt cG9zc2libGUgZml0IGZvciBvdGhlcnMuICBUaGlzIHdvdWxkIGJlIGEgdmVyeSBiYWQgdGhpbmcu DQoNCklyb25pY2FsbHksIOKAnGxvY2tpbmcgZG93buKAnSBTRVQgdG8gcmVxdWlyZSBjaG9pY2Vz IG1vdGl2YXRlZCBieSBhIHBhcnRpY3VsYXIgcHJvZmlsZSB3b3VsZG7igJl0IGhlbHAgdGhhdCBw cm9maWxlIGF0IGFsbCwgYXMgaXQgd291bGQgd29yayB0aGUgc2FtZSB3aGV0aGVyIFNFVCB3YXMg 4oCcbG9ja2VkIGRvd27igJ0gb3Igbm90LiAgQnV0IGl0IHdvdWxkIHVubmVjZXNzYXJpbHkgcHJl Y2x1ZGUgdXNlIG9mIFNFVHMgaW4gb3RoZXIgY29udGV4dHMgdGhhdCB0aGV5IGFyZSBjdXJyZW50 bHkgYSBncmVhdCBmaXQgZm9yLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1 cnRlc2N1IFttYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBKdW5l IDI2LCAyMDE3IDk6NDMgQU0NClRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpD YzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgUGhpbCBIdW50IDxw aGlsLmh1bnRAb3JhY2xlLmNvbT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5u YUBhbWF6b24uY29tPjsgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT47IEhlbmsgQmly a2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+OyBZYXJvbiBTaGVmZmVyIDx5 YXJvbmYuaWV0ZkBnbWFpbC5jb20+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3Mg VG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCkp1c3RpbiwgaW4gdGhl IGNhc2Ugd2hlbiBhbiBSUCBpcyBpc3N1aW5nIHRoZSBTRVQgdG8gc2VuZCBpdCB0byBhbiBJZFAs IGEgdG9wIGxldmVsIHN1YiBhcyB5b3UgZGVzY3JpYmUgaXQgbWF5IG5vdCBiZSBwb3NzaWJsZS4g T3IgbWF5YmUgSSBtaXN1bmRlcnN0YW5kLg0KDQpXZSBhZ3JlZSBvbiAiaXNzIiBJIHRoaW5rLCBp biB0aGlzIGNhc2UgaXQgcG9pbnRzIHRvIHRoZSBSUC4gQSB0b3AgbGV2ZWwgInN1YiIgdGhvdWdo IGlzIHByb2JsZW1hdGljLCBUaGUgUlAgaW4gbWFueSBjYXNlcyBoYXMgdGhlIG9wYXF1ZSAic3Vi IiBhcyBpc3N1ZWQgYnkgdGhlIElkUCwgYnV0IHRoaXMgdmFsdWUgaXMgZ2xvYmFsbHkgdW5pcXVl IG9ubHkgd2hlbiBjb21iaW5lZCB3aXRoIHRoZSBJZFAgImlzcyIuDQoNCk5vdCBzdXJlIHdoeSBl dmVudC5hdWQgd291bGQgYmUgbmVjZXNzYXJ5Pw0KDQpNYXJpdXMNCg0KT24gU3VuLCBKdW4gMjUs IDIwMTcgYXQgNzozMSBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpq cmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KTWlrZSwgdGhpcyBpcyBub3QgYXQgYWxsIHdoYXQg SSBzZWUgZm9yIGhhdmluZyB0aGUgIm1vc3Qgc3VwcG9ydCIuIEluc3RlYWQgSSdtIHNlZWluZyBh IGxvdCBvZiBjYWxsIGZvciBoYXZpbmcgInN1YiIgZGVmaW5lZCBjbGVhcmx5IGluIHRoZSBldmVu dCBwYXlsb2FkIG9ubHkuDQoNClRoZSAic3ViIiBvZiB0aGUgbWFpbiBib2R5IGlzIHRoZSBzdWJq ZWN0IGFzIGtub3duIGJ5IHRoZSBpc3N1ZXIgb2YgdGhlIFNFVCBpdHNlbGYuIFRoaXMgbWlnaHQg YmUgdGhlIHNhbWUgc3ViamVjdCB0aGF0IHRoZSBzdWJqZWN0IGlzIGtub3duIGJ5IGF0IHRoZSB0 YXJnZXQgb2YgdGhlIFNFVC4gVGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgdGhpcyBpc24ndCB0 cnVlLCBhbmQgc28gZmFyIG9uZSBleGNlcHRpb24gY2FzZSB3aGVyZSBpdCBpcywgc29tZXRpbWVz LiBXZSBzaG91bGQgbm90IGJlIHdyaXRpbmcgdGhpcyBmb3IgdGhlIGV4Y2VwdGlvbi4NCg0KQnV0 IEkgdGhpbmsgdGhlcmUncyBhIHByZXR0eSBjbGVhciBwYXRoIGZvcndhcmQuIFRoZSAic3ViIiBp biB0aGUgYm9keSBvZiBhIFNFVCwgaWYgaXQgaXMgaW5jbHVkZWQsIGlzICpBTFdBWVMqIGluIHRo ZSBjb250ZXh0IG9mIHRoZSAiaXNzIiBvZiB0aGUgU0VULiBBbHdheXMsIGZ1bGwgc3RvcCwgbm8g ZXhjZXB0aW9ucy4gTm8gZ2xvYmFsIG5hbWVzcGFjZXMsIG5vIHJlc3RyaWN0aW9ucyBvbiBjb250 ZW50LCBubyBmb3JtYXRzIC0tIGl0J3MgYW4gb3BhcXVlICh0byB0aGUgU0VUIHN0YW5kYXJkKSB2 YWx1ZSBpbiB0aGUgZG9tYWluIG9mIHRoZSBpc3N1ZXIgb2YgdGhlIFNFVC4NCg0KRXZlbnQgcGF5 bG9hZHMsIGRlZmluZWQgaW4gcHJvZmlsZXMsIGRlc2NyaWJlIGEgc3ViamVjdCBvZiB0aGUgZXZl bnQgaXRzZWxmLiBJbXBvcnRhbnRseSwgdGhpcyBpcyB0aGUgc3ViamVjdCBhcyBrbm93biBieSB0 aGUgY29udGV4dCBpbiB3aGljaCB0aGUgZXZlbnQgd2lsbCBiZSAqcmVjZWl2ZWQqLCBub3QgaW4g d2hpY2ggaXQgd2FzICppc3N1ZWQqLiBTb21ldGltZXMgdGhvc2UgYXJlIHRoZSBzYW1lLCBtb3Jl IG9mdGVuIChhcyB3ZSdyZSBzZWVpbmcpIHdlIGNhbid0IGd1YXJhbnRlZSB0aGF0LiBXZSBzaG91 bGQgbm90IGRlcGVuZCBvbiB0aGF0IGFuZCB3ZSBzaG91bGQgbm90IHRyZWF0IHRoZSBleGNlcHRp b25hbCBjYXNlIGFzIHRoZSB1c3VhbCwgbm8gbWF0dGVyIHdoYXQgc3ludGF4IGFub3RoZXIgZ3Jv dXAgaGFzIGNvbWUgdXAgd2l0aC4NCg0KU28gaGVyZSdzIHRoZSB0aGluZy4gSSB0aGluayB0aGUg InN1YiIgb2YgYW4gZXZlbnQgc2hvdWxkIGJlIG9wdGlvbmFsLCBhbmQgQUxXQVlTIGluIHRoZSBj b250ZXh0IG9mIHRoZSBpc3N1ZXIsIGFuZCBwcm9maWxlcyBzaG91bGQgbm90IHBsYWNlcyBmdXJ0 aGVyIGNvbnN0cmFpbnRzIG9uIHRoYXQuIEV2ZW50cyB0aGVtc2VsdmVzIHNob3VsZCBiZSBzZWxm LWNvbnRhaW5lZC4gSSByZWdyZXQgdGhhdCB3ZSBkaWRuJ3QgbWFrZSB0aGUgcmVnaXN0cmF0aW9u IG9iamVjdCBpbiBSRkM3NTkxIG1vcmUgc2VsZi1jb250YWluZWQsIGFzIHRoYXQncyBjYXVzZWQg aW1wbGVtZW50YXRpb24gYW5kIGV4dGVuc2lvbiBpc3N1ZXMuIEkgdGhpbmsgZXZlbnRzIHNob3Vs ZCBhbHdheXMgaGF2ZSBhbiBpbnRlcm5hbCBzdWJqZWN0L2lzc3VlciBwYWlyLCBpbiB0aGUgY29u dGV4dCBvZiB3aGVyZSB0aGUgZXZlbnQgaXMgYmVpbmcgY29uc3VtZWQuIFdlIG5lZWQgdG8gZGVm aW5lIHdoYXQgaXNzL3N1YiBtZWFuIChpbiBhIGdyYW5kIHNlbnNlKSBpbnNpZGUgdGhlIGV2ZW50 IG9iamVjdCBpbiB0aGlzIGRvY3VtZW50LCBzbyB0aGF0IGRpZmZlcmVudCBldmVudHMgZG9uJ3Qg cmVpbnZlbnQgdGhlIHNhbWUgdGhpbmcgb3ZlciBhbmQgb3Zlci4gSWYgYSBwcm9maWxlIHdhbnRz IHRvIGxlYXZlIHRoYXQgb3V0IGJlY2F1c2UgdGhleSBkb24ndCBuZWVkIGFuIGlkZW50aWZpZXIg Zm9yIHRoZSBwYXlsb2FkLCB0aGVuIHRoZXkgY2FuIGxlYXZlIGl0IG91dC4gSWYgdGhleSB3YW50 IHRvIGxlYXZlIGl0IG91dCBiZWNhdXNlIHRoZXkgd2FudCB0byBhc3N1bWUgdGhlcmUgd2lsbCAi YWx3YXlzIiBiZSBhbiBpc3Mvc3ViIGluIHRoZSByb290IG9mIHRoZSBTRVQsIHRoZW4gSSBoYXZl IGEgcHJvYmxlbSB3aXRoIHRoYXQuIFRoZSBpc3N1ZXIgb2YgdGhlIFNFVCBjYW4sIGFuZCBwcm9i YWJseSBkb2VzLCBoYXZlIGl0cyBvd24gaWRlbnRpZmllciB3aGljaCBjYW4ndCBiZSBhc3N1bWVk IHRvIGJlIHVuaXZlcnNhbC4gUHJvcG9zaW5nIGEgZ2xvYmFsIHN1YmplY3QgbmFtZXNwYWNlIG9y IGZvcm1hdCwgYXMgaGFzIGJlZW4gc3VnZ2VzdGVkIGVsc2V3aGVyZSBvbiB0aGlzIGxpc3QsIGlz IGx1ZGljcm91cyBhbmQgd2lsbCBuZXZlciBmbHkgYXMgaXQgZ29lcyBhZ2FpbnN0IGhvdyBKV1Qg bmFtZXNwYWNpbmcgZm9yIHBlb3BsZSBhbmQgb2JqZWN0cyBoYXMgYWx3YXlzIHdvcmtlZC4gV2Ug c2hvdWxkIGhhdmUgYSBjbGVhciBzZW1hbnRpYyBkYXRhIHN0cnVjdHVyZSB0aGF0IGNhbiBiZSBl eHRlbmRlZCBhbmQgdXNlZCBieSBhbGwgb2YgdGhlIHVzZSBjYXNlcyB0aGF0IHdlJ3ZlIGFkb3B0 ZWQuIE9wdGltaXppbmcgYXQgdGhpcyBzdGFnZSwgZXNwZWNpYWxseSBiYXNlZCBvbiBvbmUgZXZl bnQsIGlzIGdvaW5nIHRvIGp1c3QgbGVhZCB0byB0aGluZ3MgYmVpbmcgYnJva2VuIGFuZCBiYWNr LXBhdGNoZWQgbGF0ZXIgb24uIEJ1dCBpZiBvbmUgc3BlYyB3YW50cyB0byBsZWF2ZSBvdXQgdGhl IGlzcy9zdWIgaW5zaWRlIHRoZSBldmVudD8gVGhleSBjYW4gc3RpbGwgZG8gdGhhdCwgYnV0IEkg dGhpbmsgdGhhdCdzIHByZXR0eSBkYWZ0Lg0KDQoNCg0KSW4gc3VtbWFyeToNCg0KICAqICAgaXNz OiBpc3N1ZXIgb2YgdGhlIGV2ZW50DQogICogICBzdWI6IHN1YmplY3Qgb2YgdGhlIGV2ZW50IGFz IGtub3duIGJ5IHRoZSBpc3N1ZXIgb2YgdGhlIGV2ZW50DQogICogICBldmVudC5zdWI6IHN1Ympl Y3Qgb2YgdGhlIGV2ZW50IGFzIGtub3duIGJ5IHRoZSByZWNpcGllbnQgb2YgdGhlIGV2ZW50DQog ICogICBldmVudC5pc3M6IGNvbnRleHQgZm9yIHRoZSBzdWJqZWN0IG9mIHRoZSBldmVudCBhcyBr bm93biBieSB0aGUgcmVjaXBpZW50IG9mIHRoZSBldmVudA0KICAqICAgZXZlbnQuYXVkOiByZWNp cGllbnQgb2YgdGhlIGV2ZW50DQoNCg0KDQogLS0gSnVzdGluDQoNCk9uIDYvMjEvMjAxNyA3OjQ1 IFBNLCBNaWtlIEpvbmVzIHdyb3RlOg0KVGhlIHByb3Bvc2FsIHRoYXQgSSBiZWxpZXZlIGhhcyB0 aGUgbW9zdCBzdXBwb3J0IGlzIGtlZXBpbmcgdGhpbmdzIGFzIHRoZXkgYXJlLCBsZWF2aW5nIGl0 IHVwIHRvIHByb2ZpbGVzIGFuZCBhcHBsaWNhdGlvbnMgdG8gZGVmaW5lIHdoaWNoIGNsYWltcyB0 aGV5IHVzZSBhbmQgaG93IHRoZXkgdXNlIHRoZW0uDQoNCkl0IHdvdWxkIGJlIGZpbmUgZm9yIHNv bWUgcHJvZmlsZXMgdG8gdXNlIHRoZSBsYW5ndWFnZSBiZWxvdy4NCg0K4oCTIE1pa2UNCkZyb206 IFBoaWwgSHVudDxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQpTZW50OiBXZWRuZXNkYXks IEp1bmUgMjEsIDIwMTcgNjozOSBQTQ0KVG86IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlPG1h aWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6IE1hcml1cyBTY3VydGVzY3U8bWFpbHRvOm1z Y3VydGVzY3VAZ29vZ2xlLmNvbT47IEpvaG4gQnJhZGxleTxtYWlsdG86dmU3anRiQHZlN2p0Yi5j b20+OyBIZW5rIEJpcmtob2x6PG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl PjsgSnVzdGluIFJpY2hlcjxtYWlsdG86anJpY2hlckBtaXQuZWR1PjsgWWFyb24gU2hlZmZlcjxt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPjsgTWlrZSBKb25lczxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdDxtYWlsdG86aWQtZXZl bnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNj ZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpTbyBJIHVuZGVy c3RhbmQgd2hhdCBpcyBiZWluZyBwcm9wb3NlZCBpczoNCg0KSWYgdGhlIGV2ZW50IHR5cGUgdXNl cyDigJxzdWLigJ0gdG8gaWRlbnRpZnkgaXRzIHN1YmplY3QsIGFuZCB0aGUgaXNzdWVyIG9mIHRo ZSBzdWJqZWN0IGlzIGlkZW50aWNhbCB0byB0aGUgaXNzdWVyIGZvciB0aGUgZXZlbnQsIHRoZW4g 4oCcc3Vi4oCdIG1heSBiZSB1c2VkIGF0IHRoZSB0b3AgbGV2ZWwuIE90aGVyd2lzZSwgdGhlIHN1 YmplY3Qgb2YgYW4gZXZlbnQgKGUuZy4g4oCcc3Vi4oCdKSBhbmQgYW55IG90aGVyIGNsYWltcyBy ZXF1aXJlZCB0byB1bmlxdWVseSBpZGVudGlmeSB0aGUgc3ViamVjdCBNVVNUIGJlIGNvbnRhaW5l ZCBpbiB0aGUgZXZlbnQgcGF5bG9hZC4NCg0KRm9yIGV4YW1wbGUsIGFuIGlwIGFkZHJlc3Mgb2Yg MS4yLjMuNCBtaWdodCBiZSByZXByZXNlbnRlZCBpbiBhIOKAnGlwYWRkcmVzc+KAnSBjbGFpbSBk ZWZpbmVkIGluIHRoZSBldmVudCBwYXlsb2FkLiDigJxpcGFkZHJlc3PigJ064oCdMS4yLjMuNCIN CkEgU0NJTSByZXNvdXJjZSBVUkkgb2YgaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL3VzZXJzL2Fj MWZhZWJiZmQzYzQ1Y2U5YTI0MmJkMzg1OWM4MmM0IG1pZ2h0IGJlIGlkZW50aWZpZWQgaW4gdGhl IGV2ZW50IHBheWxvYWQgYXM6IOKAnHN1YuKAnToiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL3Vz ZXJzL2FjMWZhZWJiZmQzYzQ1Y2U5YTI0MmJkMzg1OWM4MmM04oCdDQoNCkEgQ29ubmVjdCBMb2dv dXQgZXZlbnQgZnJvbSBhbiBPUCB1c2VzIHRoZSB0b3AgbGV2ZWwgc3ViIGNsYWltIGFuZCBkZXBl bmRzIG9uIOKAnGlzc+KAnSBiZWluZyB0aGUgc2FtZSBmb3IgdGhlIGV2ZW50IGlzc3VlciBBTkQg dGhlIHN1YmplY3QuIFRoaXMgbWVhbnMgdGhhdCBubyBwYXJ0eSBtYXkgaXNzdWUgbG9nb3V0IGV2 ZW50cyBvbiBiZWhhbGYgb2YgdGhlIE9QLg0KDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9u LCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QgJiBTdGFuZGFyZHMNCkBpbmRlcGVu ZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0K T24gSnVuIDIxLCAyMDE3LCBhdCAzOjM4IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8 cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0K DQpGYWlyIHBvaW50LiBJZiB3ZSBkbyBub3QgaW50ZW5kIHRvIHN1cHBvcnQgbXVsdGlwbGUgcHJv ZmlsZXMgd2l0aGluIGEgc2luZ2xlIFNFVCwgdGhlbiBJ4oCZbSBsZXNzIGNvbmNlcm5lZCBhYm91 dCBsZWF2aW5nIHN1YiBzZW1hbnRpY3MgdXAgdG8gdGhlIHByb2ZpbGVzLg0KDQotLQ0KQW5uYWJl bGxlIFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBNYXJpdXMg U2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xl LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcgYXQgMjo1OCBQTQ0KVG86ICJS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20+Pg0KQ2M6ICJQaGlsIEh1bnQgKElETSkiIDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiwgSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiwgSGVuayBCaXJraG9seiA8 aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQu ZnJhdW5ob2Zlci5kZT4+LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpy aWNoZXJAbWl0LmVkdT4+LCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFp bHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+LCBNaWNoYWVsIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+LCBJRCBF dmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBU b2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KRXhhbXBsZSBmb3IgbXVs dGlwbGUgZXZlbnRzIHdpdGhpbiBzYW1lIHByb2ZpbGU6IElkUCBhY2NvdW50IGlzIGRpc2FibGVk IChiZWNhdXNlIG9mIGhpamFja2luZyksIHRoaXMgY2FuIGxlYWQgdG8gdHdvIGV2ZW50czoNCjEu ICJhY2NvdW50LWRpc2FibGVkIg0KMi4gInNlc3Npb25zLXJldm9rZWQiDQoNCk1hcml1cw0KDQpP biBXZWQsIEp1biAyMSwgMjAxNyBhdCAyOjU0IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3Rl Og0KVGhlIHNwZWMgc2F5cyB0aGF0IHRoZSBldmVudHMgY2xhaW0gU0hPVUxEIE5PVCBiZSB1c2Vk IHRvIGV4cHJlc3MgbXVsdGlwbGUgbG9naWNhbCBldmVudHMuIElmIGl04oCZcyBhbHNvIG5vdCB1 c2VkIHRvIGV4cHJlc3MgZXZlbnRzIGZyb20gZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQgY29ycmVz cG9uZCB0byB0aGUgc2FtZSBsb2dpY2FsIGV2ZW50IChlLmcuIGFuIE9JREMgYmFja2NoYW5uZWwg bG9nb3V0IGV2ZW50IGFsb25nc2lkZSBhIGh5cG90aGV0aWNhbCBSSVNDIGxvZ291dCBldmVudCks IHRoZW4gSeKAmW0gbm90IHN1cmUgd2hhdCB1c2UgY2FzZSB0aGF0IGxlYXZlcyBmb3IgbXVsdGlw bGUgZXZlbnRzIGluIG9uZSBTRVQuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJ ZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJQ aGlsIEh1bnQgKElETSkiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IGF0IDI6MTIgUE0NClRv OiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNv bT4+DQpDYzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNv bTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmto b2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVy LmRlPj4sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj4sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNj dXJ0ZXNjdUBnb29nbGUuY29tPj4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNv bTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4sIE1pY2hhZWwgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4s IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVu dEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9B Y2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNClNlcGFyYXRl IG9yIGNvbWJpbmVkIG1heSBiZSBldm9sdmluZy4gTWlrZSB3YW50cyB0byBrZWVwIHRoZSBjdXJy ZW50IGJhY2tjaGFubmVsIGxvZ291dCB2ZXJ5IG5hcnJvd2x5IHNjb3BlZC4gSGUgc3VnZ2VzdGVk IHJpc2MgZGVmaW5lIGl0cyBvd24gZHVwbGljYXRlIGRlZmluaXRpb25zIGFuZCBtZWFuaW5ncy4N Cg0KVGhhdCBsZWFkcyBtZSB0byBiZWxpZXZlIHdlIHdpbGwgaGF2ZSBtdWx0aS10eXBlIGV2ZW50 cyBpbiBwcmFjdGljZS4NCg0KU2Vzc2lvbiBjYW5jZWxsYXRpb24gY2FuIG9jY3VyIGZvciBtYW55 IHJlYXNvbnMuIE9uZSBvZiB0aGUgZGlmZmVyZW50aWF0b3JzIHdlIGhhZCB0cmllZCB0byBtYWtl IHdhcyBhbiBhc3N1bXB0aW9uIHRoYXQgdXNlciBpbml0aWF0ZWQgZXZlbnRzIHdvdWxkIGJlIHBh cnQgb2YgY29ubmVjdC4gUmlzayB3b3VsZCBjb3ZlciB2YXJpYXRpb25zIHRoYXQgZHJpdmUgb2Zm IG9mIHJpc2sgY2FsY3VsYXRpb25zIGxpa2UgcGFzc3dvcmQgcmVzZXQuDQoNClRoZXJlIGFyZSBh bHNvIHNpZ25vdXQgZXZlbnRzIGF0IHJwJ3MgdG8gbGV0IHRoZSBPUCBrbm93LiBUaGVzZSBhcmUg bm90IGNvbW1hbmRzIGJ1dCBub3RpZmljYXRpb24gdGhhdCBhIHJlc291cmNlIHNlc3Npb24gaXMg Y2FuY2VsbGVkLiBJT1cgc2luZ2xlIHNpZ24gb3V0IG5vdCBleHBlY3RlZC4NCg0KUGhpbA0KDQpP biBKdW4gMjEsIDIwMTcsIGF0IDE6NTggUE0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5j b208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQpJIHRob3VnaHQgd2UgZGVjaWRl ZCB0aGF0IHdlIGFyZSBvbmx5IGFsbG93aW5nIHNldCBtZXNzYWdlcyBmb3JtIHRoZSBzYW1lIGZh bWlseSB0aGF0IGFncmVlIG9uIHRvcCBsZXZlbCBjbGFpbXMuDQoNCk90aGVyd2lzZSB0aGVyZSBj YW4gYmUgbm8gdG9wIGxldmVsIGNsYWltcyBhbmQgd2UgYXJlIHJlYWxseSBkZWZpbmluZyBhIGFs dGVybmF0aXZlIGZvcm1hdCB0byBKV1QgaW4gc29tZSB3YXlzLg0KDQpKb2huIEIuDQoNCk9uIEp1 biAyMSwgMjAxNywgYXQgMzo1NCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hh bm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+PiB3cm90ZToNCg0KSSBh Z3JlZSB3aXRoIEpvaG4gdGhhdCB0aGUgSldUIHR5cGUgY29uZnVzaW9uIHByb2JsZW0gYW5kIHRo ZSBTRVQgc3ViIHByb2JsZW0gY2FuIGFuZCBzaG91bGQgYmUgZGlzY3Vzc2VkIHNlcGFyYXRlbHku IFRoZSBzZWNldmVudHMgV0cgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCBzZXR0aW5nIHRvIGRp c2N1c3MgdGhlIGZvcm1lci4NCg0KTXkgY29uY2VybiB3aXRoIHRoZSBzdWIgY2xhaW0gaXMgdGhh dCB0d28gcHJvZmlsZXMgbWF5IGRpY3RhdGUgY29uZmxpY3Rpbmcgc2VtYW50aWNzIChlLmcuIFBy b2ZpbGUgQSBzYXlzIGl04oCZcyBhIHBob25lIG51bWJlciwgUHJvZmlsZSBCIHNheXMgaXTigJlz IGFuIGVtYWlsIGFkZHJlc3MpLiBJZiB0aGVzZSBwcm9maWxlcyBkb27igJl0IHByb3ZpZGUgYW4g YWx0ZXJuYXRlIHdheSB0byBkZWNsYXJlIHN1YmplY3Qgb2YgdGhlaXIgZXZlbnRzLCB0aGVuIHRo ZXkgY2Fubm90IGJlIHByZXNlbnQgd2l0aGluIHRoZSBzYW1lIHRva2VuLiBUaGlzIGluY29tcGF0 aWJpbGl0eSB0cmFwIHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgY291bGQgYmUgZWFzaWx5IG1p c3NlZCBieSBncm91cHMgcHJvZmlsaW5nIFNFVC4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSm9obiBCcmFkbGV5IDx2ZTdqdGJA dmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBK dW5lIDIxLCAyMDE3IGF0IDE6MzkgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpDYzogSnVzdGluIFJpY2hl ciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiwgTWFyaXVzIFNjdXJ0 ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+ PiwgQW5uYWJlbGxlIFJpY2hhcmQgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5h QGFtYXpvbi5jb20+PiwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiwgTWljaGFlbCBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiwgSUQgRXZlbnRzIE1h aWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4s IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhl bmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0g c29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBp c3N1ZXINCg0KSW4gdGhlIGVudmVsb3BlIHR5cCBpcyBhIG1lZGlhL21pbWUgdHlwZS4gIFJlZ2lz dGVyaW5nIGFwcGxpY2F0aW9uL2lkdCtqd3QgaWYgd2UgcmVnaXN0ZXIgand0IGFzIGEgc3RydWN0 dXJlZCBuYW1lIHN1Zml4Lg0KDQpVc2luZyB0aGUgY3R5IGlzIGFsc28gcG9zc2libGUuICAgSSBu ZWVkIHRvIHRoaW5rIGFib3V0IHdoYXQgaXMgYmV0dGVyIGJ1dCB3ZSBjYW4gYWdyZWUgb24gYSBj b252ZW50aW9uLg0KDQpOb3QgZXZlcnl0aGluZyBpcyBnb2luZyB0byBiZSBhIHNldCB0b2tlbiBs aWtlIG5vdCBldmVyeSBKV1MgaXMgYSBKV1QuDQoNCklmIHdlIGFyZSBnb2luZyB0byBkZWZpbmUg cHJvY2Vzc2luZyBydWxlcyB0byBzdG9wIGNvbGxpc2lvbnMgYW5kIGNvbmZ1c2lvbiBhcm91bmQg SldUIGZvciBkaWZmZXJlbnQgcHVycG9zZXMsIHdlIHNob3VsZCBqdXN0IHN0YXJ0IHVzaW5nIHRo ZSB0eXAgcGFyYW1ldGVyIGJhc2VkIG9uIHRoZSBleGlzdGluZyBzcGVjLg0KDQpJbiBnZW5lcmFs IGNvbnRlbnQgc25pZmZpbmcgaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBvcHRpb24gZXZlbnR1 YWxseSBnZXRzIHlvdSBpbnRvIHRyb3VibGUuDQoNCkkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IGZv cmNpbmcgdGhlcmUgdG8gYmUgbm8gc3ViIGF0IHRoZSB0b3AgbGV2ZWwgaXMgYSBnb29kIGlkZWEu DQoNCkl0IGlzIG5vdCB0aGUgd2F5IHdlIHNob3VsZCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gU0VU IGFuZCBpZF90b2tlbnMuDQoNCklmIHN1YiBpcyBub3QgYWxsb3dlZCBhdCB0aGUgdG9wIGxldmVs IHBlb3BsZSB3aWxsIGRvIG5vbiBTRVQgSldUIGZvciB0aGluZ3Mgd2hlcmUgdGhlIHN1YmplY3Qg aXMgc2NvcGVkIHRvIHRoZSBpc3Mgb2YgdGhlIHRva2VuLg0KDQpJIHRoaW5rIGRlZmluaW5nIHN1 YiB0byBiZSBwYXJ0IG9mIHRoZSBldmVudCBmb3IgY2FzZXMgd2hlcmUgdGhlIHN1YiBpcyBzY29w ZWQgZGlmZmVyZW50bHkgZnJvbSB0aGUgaXNzdWVyIG9mIHRoZSB0b2tlbiBpcyBmaW5lLCBidXQg c2hvdWxkIG5vdCBiZSByZXF1aXJlZCBmb3IgYWxsIGV2ZW50IHR5cGVzLg0KDQpJIHRoaW5rIHdl IHNob3VsZCBzb2x2ZSB0aGUgY29uZnVzaW9uIGlzc3VlIHNlcGFyYXRlbHkgZnJvbSB0aGUgc3Vi IGlzc3VlLg0KDQpTb3JyeSBJIGFtIGF0IENJUyBzbyB0cnlpbmcgdG8gY2F0Y2ggdXAgb24gbGlz dHMuDQoNCkpvaG4gQi4NCg0KT24gSnVuIDE3LCAyMDE3LCBhdCAzOjQ1IFBNLCBZYXJvbiBTaGVm ZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+ IHdyb3RlOg0KDQpTbyB0byBzdW1tYXJpemUgd2hhdCBJJ20gc2VlaW5nIG9uIHRoaXMgdGhyZWFk Og0KRXZlcnlib2R5IGFncmVlcyB3aXRoIE1hcml1cydzIHNob3J0LXRlcm0gc29sdXRpb24sIHNw ZWNpZmljIHJ1bGVzIGZvciAic3ViIiBhbmQgImlzcyIgdGhhdCBjYW4gYmUgZGVmaW5lZCBpbiB0 aGUgU0VUIHNwZWMuDQpBbG1vc3QgZXZlcnlib2R5IGFncmVlcyBvbiBhIGxvbmctdGVybSAidXNh Z2UiIGNsYWltICgidHlwZSIgaXMgdGFrZW4pIHRoYXQgc2hvdWxkIGJlIGRlZmluZWQgZWxzZXdo ZXJlLCBlLmcuIGluIHRoZSBKV1QgQkNQLg0KRGlkIEkgbWlzcyBhbnl0aGluZz8NCkJ5IHRoZSB3 YXksIGlmIHdlIGRvIGFkZCBhICJ1c2FnZSIgY2xhaW0sIHdlIG5lZWQgdG8gYWxzbyB1c2UgaXQg aW4gdGhlIFNFVCBkb2N1bWVudCBiZWZvcmUgaXQgaXMgcHVibGlzaGVkLg0KVGhhbmtzLA0KICAg IFlhcm9uDQoNCk9uIDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmljaGVyIHdyb3RlOg0KKzEgdG8g dGhpcyBhcyB3ZWxsLg0KDQog4oCUIEp1c3Rpbg0KDQpPbiBKdW4gMTUsIDIwMTcsIGF0IDE6MDkg UE0sIE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCisxIHRvIHdoYXQgQW5uYWJlbGxlIHNhaWQuDQoN CkFsc28sIE1pa2UgeW91IGFyZSBtaXNzaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudCwgZm9yIFJQ cyB0byBzZW5kIGV2ZW50cyB0byBhbiBJZFAuIFRoZSBpc3Mrc3ViIHBhaXIgYXQgdGhlIHRvcCBs ZXZlbCBpcyBicm9rZW4gaW4gdGhpcyBjYXNlLg0KDQpNYXJpdXMNCg0KT24gV2VkLCBKdW4gMTQs IDIwMTcgYXQgNTozMyBQTSwgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCisxDQoNClBoaWwNCg0KT24gSnVu IDE0LCAyMDE3LCBhdCA1OjI1IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFu bmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KTWlrZSwN Cg0KWW91ciBleHBsYW5hdGlvbiBmb3Igd2h5IHRoaXMgaXMgYSBub24tcHJvYmxlbSBpcyBkZXBl bmRlbnQgdXBvbiBzaWRlIGVmZmVjdHMgb2YgZWxlbWVudHMgb2YgT3BlbklEIENvbm5lY3QgdGhh dCB3ZXJlIG5vdCBkZXNpZ25lZCB0byBzb2x2ZSB0aGlzIGlzc3VlLiBBcyBhIHJlc3VsdCwgSSBz ZWUgc2V2ZXJhbCBpc3N1ZXMgd2l0aCBpdDoNCg0KMS4gICAgICAgVGhlIGNhbGxlciBvZiB0aGUg VG9rZW4gRW5kcG9pbnQgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBjYW4gYmUgY2VydGFpbiB0aGF0 IGEgbm9uY2UtbGVzcyBJRCBUb2tlbiBpcyByZWFsbHkgYW4gSUQgVG9rZW4uIEFueSBwYXJ0eSB0 aGF0IHRoZSBjYWxsZXIgcGFzc2VzIHRoZSBJRCBUb2tlbiBvZmYgdG8gaGFzIG5vIHdheSB0byB2 ZXJpZnkgaXRzIHByb3ZlbmFuY2UuDQoNCjIuICAgICAgIEFueSBmdXR1cmUgSUQgVG9rZW4gZGlz dHJpYnV0aW9uIG1ldGhvZCBuZWVkcyB0byBzb2x2ZSB0aGlzIHByb2JsZW0gYWdhaW4uDQoNCjMu ICAgICAgTm8gb3RoZXIgcHJvZmlsZSBvZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAibm9uY2XigJ0g Y2xhaW0uDQoNCjQuICAgICAgVGhpcyBpcyBvbmx5IGEgc29sdXRpb24gZm9yIElEIFRva2Vucy4g RXZlcnkgb3RoZXIgSldUIHByb2ZpbGUgdGhhdCBjYXJlcyBhYm91dCBkaXNhbWJpZ3VhdGlvbiBo YXMgdG8gaW52ZW50IGl0cyBvd24gc29sdXRpb24gdG8gdGhlIHByb2JsZW0uDQoNCldlIGtub3cg ZnJvbSBleHBlcmllbmNlIHRoYXQgbmFtaW5nIGNvbGxpc2lvbnMgYW5kIHJlcGxheSBhdHRhY2tz IGFyZSBib3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4gV2hhdOKAmXMgYmVpbmcgcHJvcG9zZWQgaXMg YSBzaW1wbGUsIGRlZmVuc2l2ZSBtZWFzdXJlIGFnYWluc3QgdGhlc2Ugcmlza3MuIFlvdSBicm91 Z2h0IHVwIEpXVCBsaWJyYXJpZXM6IGEgZ2VuZXJhbCBzb2x1dGlvbiBhY3R1YWxseSBtYWtlcyBp dCBlYXNpZXIgdG8gdXNlIGNvbW1vbiBsaWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBBIOKAnHVz YWdlLWF3YXJl4oCdIEpXVCBsaWJyYXJ5IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlvbiBmb3Ig YW55IEpXVCBwcm9maWxlLCB3aGVyZWFzIHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBwcm9maWxl IHdvdWxkIHJlcXVpcmUgdW5pcXVlIGxvZ2ljLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bmUgMTQsIDIwMTcg YXQgMToxNiBQTQ0KVG86IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxt YWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPj4NCkNjOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5h YmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4s IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVu dEBpZXRmLm9yZz4+LCBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVy LmRlPG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NClN1YmplY3Q6IFJl OiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBk aXN0aW5jdCBTRVQgaXNzdWVyDQoNCllvdeKAmXZlIGhlYXJkIG9mIOKAnHByZW1hdHVyZSBvcHRp bWl6YXRpb27igJ0uICBJ4oCZZCBjaGFyYWN0ZXJpemUgdGhlIHByb3Bvc2FscyBpbiB0aGlzIHRo cmVhZCBhcyDigJxwcmVtYXR1cmUgcGVzc2ltYXRpb27igJ0g4oCTIG1ha2luZyB0aGluZ3MgdGhh dCBjYW4gYW5kIHNob3VsZCBiZSBzaW1wbGUgY29tcGxleCwgd2l0aG91dCBkYXRhIHNob3dpbmcg dGhlcmXigJlzIGFueSBuZWVkIHRvIGRvIHNvLg0KDQpNYW5kYXRvcnkgc29sdXRpb25zIGFyZSBi ZWluZyBwcm9wb3NlZCBpbiB0aGlzIHRocmVhZCB0byBwcm9ibGVtcyB0aGF0IHRoZXJl4oCZcyBu byBldmlkZW5jZSB0aGF0IHdlIGFjdHVhbGx5IGV2ZW4gaGF2ZS4gIEl04oCZcyBhbHJlYWR5IGJl ZW4gZXN0YWJsaXNoZWQgdGhhdCBpdOKAmXMgaW1wb3NzaWJsZSBmb3IgYSBTRVQgdG8gYmUgY29u ZnVzZWQgZm9yIGFuIElEIFRva2VuIOKAkyBzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwNDI4Lmh0bWw8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbC0y RGFyY2hpdmVfd2ViX2lkLTJEZXZlbnRfY3VycmVudF9tc2cwMDQyOC5odG1sJmQ9RHdNR2FRJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9ZUtMVFFQbVlyVjNUaGZEYm45MFNDczU1VVJPVFBpbl9s Z2M2UmRyNVhvdyZlPT4uICBJZiBwZW9wbGUgaGF2ZSBkYXRhIHNob3dpbmcgdGhhdCB0aGlzIGlz IHBvc3NpYmxlIHdpdGggc3BlY2lmaWMga2luZHMgb2YgQWNjZXNzIFRva2VucyBvciBvdGhlciBy ZWFsIEpXVCBkZXBsb3ltZW50cywgcGxlYXNlIHByb3ZpZGUgc3BlY2lmaWNzLCBzbyB0aGF0IHdl IGNhbiB1c2UgdGhhdCBkYXRhIHRvIGluZm9ybSBhcHByb3ByaWF0ZSBlbmdpbmVlcmluZyBjaG9p Y2VzIG9uIG91ciBwYXJ0Lg0KDQpUaGUgcHJvcG9zZWQg4oCcc29sdXRpb25z4oCdLCBzdWNoIGFz IHByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIGluIHRoZSBub3JtYWwgd2F5LCBvciBy ZXF1aXJpbmcgYSB0eXBlIGNsYWltLCB3b3VsZCBtYWtlIHByZXZpb3VzbHkgc2ltcGxlIHRoaW5n cyB1bm5lY2Vzc2FyaWx5IGNvbXBsZXguICBZZXMsIHRoZW4gdGhlIHJlc3VsdCBpcyB0aGVuIGRp ZmZlcmVudCB0aGFuIGEgbm9ybWFsIEpXVCBidXQgYSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRo YXQgY3VzdG9tIHBhcnNpbmcgY29kZSB3b3VsZCBoYXZlIHRvIGJlIHVzZWQsIHJhdGhlciB0aGFu IGEgc3RhbmRhcmQgSldUIHBhcnNlci4gIFRoZSBtb3JlIHVud2llbGR5IHdlIG1ha2UgaXQgdG8g dXNlIFNFVHMsIHRoZSBtb3JlIGxpa2VseSBkZXZlbG9wZXJzIGFyZSB0byBqdXN0IGNyZWF0ZSB0 aGVpciBvd24gZGF0YSBzdHJ1Y3R1cmVzLiAgS2VlcGluZyBpdCBzaW1wbGUgaXMgdGhlIGtleSB0 byBhZG9wdGlvbi4gIFN0YW5kYXJkcyBhcmUgb25seSB1c2VmdWwgaWYgdGhleSBhcmUgYWN0dWFs bHkgdXNlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZQ0KU2VudDogVHVl c2RheSwgSnVuZSAxMywgMjAxNyA1OjMzIFBNDQpUbzogTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PjsgSGVuayBCaXJr aG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9s ekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpDYzogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZl bnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQt ZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5j dCBTRVQgaXNzdWVyDQoNCkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjogY2FuIHlvdSBleHBs YWluIHdoYXQgeW91IG1lYW4gYnkg4oCcaW50ZW5k4oCdPw0KDQpUbyB5b3VyIGZpcnN0IHF1ZXN0 aW9uLCBJIHRoaW5rIGEgYmV0dGVyIGFuYWxvZ3kgd291bGQgYmUgdGhlIFguNTA5IEtleSBVc2Fn ZSBleHRlbnNpb246IGEgbXVsdGktdmFsdWVkIHByb3BlcnR5IHRoYXQgZGVjbGFyZXMgdGhlIGlu dGVuZGVkIHB1cnBvc2Ugb2YgdGhlIEpXVCwgYW5kIHRoYXQgYSByZWNpcGllbnQgbWF5IHJlZmVy IHRvIHdoZW4gZGV0ZXJtaW5pbmcgd2hldGhlciB0byBhY2NlcHQgYSBKV1QgYmVpbmcgcHJlc2Vu dGVkIHRvIGl0IGluIHNvbWUgY29udGV4dC4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2tt YW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgSnVuZSAxMywgMjAxNyBhdCAxMTowNSBB TQ0KVG86IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFp bHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0KQ2M6IElEIEV2ZW50cyBNYWls aW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1 c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpPbiBUdWUsIEp1biAxMywgMjAxNyBhdCAy OjExIEFNLCBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1h aWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4gd3JvdGU6DQpBbmQgYSAybmQg cXVlc3Rpb24uDQoNCldoYXQgc2VtYW50aWNzIHdvdWxkICJ1c2FnZSIgcHJvdmlkZSB0aGF0IHRo YXQgYXJlIG5vdCBjb3ZlcmVkIHZpYSAiaW50ZW5kIiwgImF1ZGllbmNlIiwgYW5kICJzY29wZSI/ DQoNCiJhdWQiIChhdWRpZW5jZSkgc3BlY2lmaWVzIHRoZSB0YXJnZXQgY2xpZW50LCBidXQgbm90 IHRoZSBpbnRlbmRlZCB1c2FnZSAoYWNjZXNzIHRva2VuIHRvIGF1dGhvcml6ZSByZXNvdXJjZSBh Y2Nlc3Mgb3IgU0VUIHRvIGNvbW11bmljYXRlIGEgc2VjdXJpdHkgZXZlbnQ/KQ0KDQoic2NvcGUi IGlzIG5vdCB1c2VkIGJ5IFNFVC4NCg0KSSBkb24ndCBrbm93IHdoYXQgZG8geW91IG1lYW4gYnkg ImludGVuZCIgKG9yIGludGVudCk/DQoNCg0KDQoNCkhlbmsNCg0KT24gMDYvMTMvMjAxNyAwMTow MSBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgd3JvdGU6DQpUaGFua3MgZm9yIHB1dHRp bmcgdGhpcyB0b2dldGhlciENCg0KSSB0aGluayB0aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQgaW4g My45IGFyZSBmbGF3ZWQ6DQoNCsK3V2UgY2Fu4oCZdCBndWFyYW50ZWUgdGhhdCBldmVyeSB0eXBl IG9mIEpXVCB3aWxsIGhhdmUgYSBtdXR1YWxseSBleGNsdXNpdmUgc2V0IG9mIHZhbGlkIGNsYWlt cyBhbmQvb3IgaGVhZGVyIHBhcmFtZXRlcnMsIGFuZCBlbmZvcmNpbmcgdGhpcyByZXF1aXJlcyBh IOKAnGZhaWwgb24gYW4gdW5yZWNvZ25pemVkIGNsYWlt4oCdIGFwcHJvYWNoIHRvIGVuc3VyZSB0 aGF0IEpXVHMgZnJvbSBzb21lIGZ1dHVyZSBzcGVjIGNhbuKAmXQgYmUgbWlzdGFrZW4gZm9yIEpX VHMgZnJvbSBhIGN1cnJlbnQgc3BlYy4NCg0KwrdJdCBpcyB1bnJlYWxpc3RpYyB0byBleHBlY3Qg aW1wbGVtZW50ZXJzIHRvIGFkaGVyZSB0byB0aGUg4oCcZGlmZmVyZW50IGtleXMgZm9yIGRpZmZl cmVudCBraW5kcyBvZiBKV1Rz4oCdIHJ1bGUuIFdoZXRoZXIgbWFuZGF0ZWQgYnkgdGhlIHNwZWMg b3Igbm90LCBpbXBsZW1lbnRlcnMgd2lsbCBpZ25vcmUgdGhpcyBiZWNhdXNlIG1hbmFnaW5nIG9u ZSBrZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZmZXJlbnQga2V5cy4NCg0KwrdEaXR0 byBmb3Ig4oCcYXVk4oCdIGFuZCDigJxpc3PigJ0gY2xhaW1zLg0KDQorMSBmb3IgYSDigJx0eXBl 4oCdIG9yIOKAnHVzYWdl4oCdIGNsYWltL2hlYWRlciBwYXJhbWV0ZXIuDQoNCi0tDQoNCkFubmFi ZWxsZSBSaWNoYXJkIEJhY2ttYW4NCg0KSWRlbnRpdHkgU2VydmljZXMNCg0KKkZyb206ICpJZC1l dmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KKkRhdGU6ICpNb25kYXksIEp1bmUgMTIsIDIw MTcgYXQgMzoxOCBQTQ0KKlRvOiAqTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pg0KKkNjOiAqQWRhbSBEYXdlcyA8YWRh d2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4sICJtYXRha2UsIG5vdiIg PG5vdkBtYXRha2UuanA8bWFpbHRvOm5vdkBtYXRha2UuanA+PiwgSUQgRXZlbnRzIE1haWxpbmcg TGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3JnPj4sICJQaGls IEh1bnQgKElETSkiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+Pg0KKlN1YmplY3Q6ICpSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNz IFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpBZ3JlZWQuIE5vdGUg dGhhdCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hhdCBzaG91bGQgYmUg aW4gMy45Lg0KDQpPbiBNb24sIEp1biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMgU2N1cnRl c2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT48 bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29t Pj4+IHdyb3RlOg0KDQogICAgVGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2ZXJ5IGdvb2Qg dGltaW5nIDotKQ0KDQogICAgVGhlIGlzc3VlIGlzIGRlc2NyaWJlZCBieSAiMi43LiBDcm9zcy1K V1QgQ29uZnVzaW9uIiBhbmQgdGhlDQogICAgbWl0aWdhdGlvbiBpcyBpbiAiMy45LiBVc2UgTXV0 dWFsbHkgRXhjbHVzaXZlIFZhbGlkYXRpb24gUnVsZXMgZm9yDQogICAgRGlmZmVyZW50IEtpbmRz IG9mIEpXVHMiLCBzcGVjaWZpY2FsbHkgIlVzZSBkaWZmZXJlbnQgc2V0cyBvZg0KICAgIHJlcXVp cmVkIGNsYWltcy4uLiIsICJVc2UgZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBv Zg0KICAgIEpXVHMuIiBhbmQgIlVzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtp bmRzIG9mIEpXVHMuIi4NCg0KICAgIEkgc3RpbGwgdGhpbmsgdGhhdCBhICJ0eXBlIiBjbGFpbSB3 b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFuZA0KICAgIHNhZmV0eS4NCg0KDQogICAgTWFy aXVzDQoNCiAgICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6NTkgUE0sIERpY2sgSGFyZHQgPGRp Y2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCiAgICA8bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+PiB3 cm90ZToNCg0KICAgICAgICBZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hlZCBhbiBCQ1Ag SUQgZm9yIEpXVA0KICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNjkwPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19zZWxmLTJEaXNz dWVkLmluZm9fLTNGcC0zRDE2OTAmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0 Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1h N1h2WjVqVGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmU9Pg0KDQogICAgICAg IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTowMiBQTSBBZGFtIERhd2VzIDxhZGF3ZXNAZ29vZ2xl LmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+DQogICAgICAgIDxtYWlsdG86YWRhd2VzQGdv b2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4+IHdyb3RlOg0KDQogICAgICAgICAg ICBJIHdhcyBpbml0aWFsbHkgYSBmYW4gb2Yga2VlcGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxh ciB0bw0KICAgICAgICAgICAgaWQgdG9rZW5zIGJ1dCBJIG5vdyB0aGluayB0aGlzIGlzIGEgYmV0 dGVyIHBsYW4uDQoNCiAgICAgICAgICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBt YXRha2UsIG5vdiA8bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4NCiAgICAgICAg ICAgIDxtYWlsdG86bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4+PiB3cm90ZToN Cg0KICAgICAgICAgICAgICAgICsxIGVzcGVjaWFsbHkgZm9yICJ0eXBlIg0KDQogICAgICAgICAg ICAgICAgMjAxNy0wNi0wOSAxMDozMiBHTVQrMDk6MDAgUGhpbCBIdW50IChJRE0pDQogICAgICAg ICAgICAgICAgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bT4+PjoNCg0KICAgICAgICAgICAgICAgICAgICArMQ0KDQogICAgICAgICAgICAgICAgICAgIFBo aWwNCg0KDQogICAgICAgICAgICAgICAgICAgICA+IE9uIEp1biA4LCAyMDE3LCBhdCA2OjI4IFBN LCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAgICAgICAgICAgICAgIDxtc2N1cnRlc2N1QGdvb2ds ZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAgICAgICAgICAg PG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNv bT4+PiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAg ID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvDQogICAgICAgICAg ICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFjY2VzcyBUb2tl bnMgaW4NCiAgICAgICAgICAgICAgICAgICAgc3VjaCBhIHdheSB0aGF0IG5haXZlIGltcGxlbWVu dGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAgICAgICAgICAgICBjb25mdXNlIG9uZSBmb3IgdGhl IG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5DQogICAgICAgICAgICAgICAgICAgIHZ1bG5lcmFi aWxpdGllcy4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4g VGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlDQogICAgICAg ICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVudCBm cm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAic3ViIiBpc3N1ZXIuIFRoaXMgaXMgdGhlIGNh c2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQogICAgICAgICAgICAgICAgICAgIHRvIGFuIElkUC4N CiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gV2l0aCB0aGVz ZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlDQogICAgICAgICAgICAgICAgICAg IGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgID4gLSBib3RoICJzdWIiIGFuZCAiaXNz IiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudA0KICAgICAgICAgICAgICAgICAgICBsZXZlbA0K ICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3Ag U0VUIGxldmVsIGNhbg0KICAgICAgICAgICAgICAgICAgICBiZSBkaWZmZXJlbnQNCiAgICAgICAg ICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQgInN1YiIgYXQgZXZlbnQgbGV2ZWwgY2FuIGJlIGRp ZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICBhY3Jvc3MgZXZlbnRzIGluIHRoZSBzYW1lIFNF VA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJzdWIiIHNob3VsZCBOT1QgYmUgcHJlc2VudCBh dCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAgICAgICAgICBsZXZlbCAodGhpcyBzb2x2ZXMgdGhl IGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUNCiAgICAgICAgICAgICAgICAgICAgInNob3Vs ZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAg ICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQgcHJvZmlsZXMgdGhh dA0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVmaW5lIGFkZGl0 aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAgICAgICAgIHJlbGF0ZWQgdG8gc3ViIChsaWtlIGVt YWlsIG9yIHBob25lX251bWJlcikgYW5kDQogICAgICAgICAgICAgICAgICAgIHNpbmNlIGFsbCB0 aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWwNCiAgICAgICAgICAgICAgICAg ICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS4NCiAgICAgICAgICAg ICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5vdGhlciBwcm9wb3NhbCAod2hp Y2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgYSBjb21w b3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmcNCiAgICAgICAgICAgICAgICAg ICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0ICBTRVQgaXNzdWVyLiBBbHNvLA0KICAg ICAgICAgICAgICAgICAgICBoYXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZpbmcgZGlmZmVy ZW50IHN5bnRheA0KICAgICAgICAgICAgICAgICAgICBpbiBkaWZmZXJlbnQgdG9rZW4gdHlwZXMg Y291bGQgbGVhZCB0byBjb25mdXNpb24uDQogICAgICAgICAgICAgICAgICAgICA+DQogICAgICAg ICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50cm9kdWNl IGEgbmV3DQogICAgICAgICAgICAgICAgICAgIGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5lcyBh ICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAgICAgICAgICAgICAgICAgcHJhY3RpY2FsIGluIHRo ZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3QNCiAgICAgICAgICAgICAgICAgICAgc29s dmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBidXQgSSB0aGluaw0KICAgICAg ICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNob3VsZCBzZXJp b3VzbHkNCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIuDQogICAgICAgICAgICAgICAgICAg ICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRob3VnaHRzPw0KICAgICAgICAgICAgICAgICAg ICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBNYXJpdXMNCg0KICAgICAgICAgICAgICAgICAg ICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg ICAgICAgICAgICAgICAgICAgPiBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAg ICAgICAgID4gSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAg ICAgICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1 WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJm09Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlSaUhxV2dmeHFtZyZzPTV4UXF2 QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZKTGh4V0kmZT0NCg0KICAgICAgICAgICAg ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgICAgICAgICAgICAgICAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICAgICAgICAgICAg ICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAgICAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAw WV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dX cyZlPT4NCg0KICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQog ICAgICAgICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3Jn PiA8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQog ICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NE ZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1Rt R01TV1dzJmU9Pg0KDQogICAgICAgICAgICAtLQ0KICAgICAgICAgICAgQWRhbSBEYXdlcyB8IFNy LiBQcm9kdWN0IE1hbmFnZXIgfGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xl LmNvbT4NCiAgICAgICAgICAgIDxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdl c0Bnb29nbGUuY29tPj4gfCsxIDY1MC0yMTQtMjQxMDx0ZWw6JTJCMSUyMDY1MC0yMTQtMjQxMD4N CiAgICAgICAgICAgIDx0ZWw6KDY1MCklMjAyMTQtMjQxMDx0ZWw6JTI4NjUwJTI5JTIwMjE0LTI0 MTA+Pg0KDQogICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAgICAg ICBJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+IDxtYWlsdG86SWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPj4NCiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVj JnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KICAg ICAgICAtLQ0KICAgICAgICBTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSA8aHR0cDovL2hhcmR0 d2FyZS5jb20vPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw LTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJL Q1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRD X2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPWk3 NVV3OGFlaFl2bHBJWk5MN054cUd4aGgxVE9yUU9VWDJYTVlCZXJWODAmZT0+PiBtYWlsIGxpc3Qg dG8NCiAgICAgICAgbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQoNCg0K LS0NCg0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6Ly9oYXJkdHdhcmUuY29tLzxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3 YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVz bGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1pNzVVdzhhZWhZdmxw SVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFpbCBsaXN0IHRvIGxlYXJuIGFi b3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2 ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kw NTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1V c2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0Za WVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtL WTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZt PVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1QN21adUd6c3NL RlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9Pg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJ ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xO S2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMm cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmU9DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWls aW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smbT1sLU84Mk5MSS1iOFFEbDJROVRrcFZvYlF6M2hfNFR5QkdBcTVwZlpzT2N3 JnM9MExXUmxHVElxaVRzRGhtSHVSSUI1LVJSZnQ4MkM3MjktUEVZSmhMdTVTUSZlPT4NCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KSWQt ZXZlbnQgbWFpbGluZyBsaXN0DQoNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPWwtTzgyTkxJLWI4UURsMlE5VGtwVm9iUXozaF80 VHlCR0FxNXBmWnNPY3cmcz0wTFdSbEdUSXFpVHNEaG1IdVJJQjUtUlJmdDgyQzcyOS1QRVlKaEx1 NVNRJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2 ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09bC1PODJOTEktYjhRRGwyUTlUa3BWb2JRejNo XzRUeUJHQXE1cGZac09jdyZzPTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0ODJDNzI5LVBFWUpo THU1U1EmZT0+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklk LWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZC1ldmVudDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed01HYVEmYz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPWwtTzgyTkxJLWI4UURsMlE5VGtwVm9i UXozaF80VHlCR0FxNXBmWnNPY3cmcz0wTFdSbEdUSXFpVHNEaG1IdVJJQjUtUlJmdDgyQzcyOS1Q RVlKaEx1NVNRJmU9Pg0KDQoNCg0KDQo= --_000_CY4PR21MB05045836B0610DDAD95B0039F5DF0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5tLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1zdHlsZS1zcGFuDQoJ e21zby1zdHlsZS1uYW1lOm1fLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1zdHlsZS1zcGFuO30N CnNwYW4ubS02NjU2OTcyOTQzNjg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOm1fLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5tLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV8tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYy OTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpwLm0tNjY1Njk3Mjk0MzY4 NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OG05MDk0MDg5MjM5NjY4NTcwMzEybXNvbGlzdHBh cmFncmFwaCwgbGkubS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkw OTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoLCBkaXYubS02NjU2OTcyOTQzNjg1MzQy MTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdy YXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1Njkz ODUxNTk5ODhtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTA3 MzEyNDMwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTEwNjA4NzAyODt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5KdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5UaGUgcnVsZXMgeW914oCZcmUgcHJvcG9zaW5nIG1heSBiZSBmaW5l IGZvciBhIFNFVCBwcm9maWxlIGZvciBhIHBhcnRpY3VsYXIga2luZCBvZiBhcHBsaWNhdGlvbi4m bmJzcDsgSSBlbmNvdXJhZ2UgeW91IHRvIGpvaW4gdGhlIFJJU0Mgd29ya2luZyBncm91cCBhbmQg d29yayBvbiB0aGVtIHRoZXJlLiZuYnNwOyBCdXQgdGhleSB3b3VsZCBsaW1pdCB0aGUgdXNlIGNh c2VzIHRoYXQNCiBTRVRzIGNvdWxkIGJlIHVzZWQgZm9yLCB3aGljaCB3b3VsZCBiZSB1bmZvcnR1 bmF0ZSBhbmQgdW5uZWNlc3NhcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5BbiBhbmFsb2d5IHdpdGggSldUIGlzIGlsbHVzdHJhdGl2ZS4mbmJzcDsgSldUIGlzIGludGVu dGlvbmFsbHkgZ2VuZXJhbC1wdXJwb3NlLCBsZWF2aW5nIGl0IHVwIHRvIGFwcGxpY2F0aW9uIHBy b2ZpbGVzIHdoYXQgY2xhaW1zIHRvIHVzZSBhbmQgd2hhdCB0aGVpciBzZW1hbnRpY3MgYXJlLiZu YnNwOyBUaGlzIGVuYWJsZXMgSldUcyB0byBiZSB1c2VkIGZvcg0KPGEgaHJlZj0iaHR0cDovL29w ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNJRFRva2VuIj5JRCBU b2tlbnM8L2E+IGFuZCBhbHNvIGZvciBjb21wbGV0ZWx5IHVucmVsYXRlZCB1c2VzLCBzdWNoIGFz DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODA1NSI+U0lQPC9hPiBh bmQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3Rpci1w YXNzcG9ydC0xMSI+DQpDYWxsZXIgSUQ8L2E+LiZuYnNwOyBUaGVyZSBpcyBubyBleHBlY3RhdGlv biBvZiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gdGhlc2UgZGlmZmVyZW50IEpXVCBhcHBsaWNh dGlvbnMuJm5ic3A7IEluZGVlZCDigJMgYm90aCB0aGUgc3ludGF4ICo8Yj5hbmQgdGhlIHNlbWFu dGljczwvYj4qLCBzdWNoIGhhcyBob3cgdG8gZGV0ZXJtaW5lIHdoYXQga2V5cyBhcmUgdmFsaWQs IGFyZSBkaWZmZXJlbnQuJm5ic3A7IEl04oCZcyB0aGlzIGZsZXhpYmlsaXR5IHRoYXQgbWFrZXMg SldUcw0KIGdlbmVyYWwtcHVycG9zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPkxpa2V3aXNlLCBTRVQgYXMgY3VycmVudGx5IHNwZWNpZmllZCBpcyBzaW1pbGFybHkgZ2Vu ZXJhbC1wdXJwb3NlLiZuYnNwOyBBcHBsaWNhdGlvbiBwcm9maWxlcyBkZWZpbmUgd2hhdCBTRVQg Y2xhaW1zIHRvIHVzZSBhbmQgdGhlaXIgc2VtYW50aWNzLiZuYnNwOw0KPGI+VGhlcmUgaXMgbm8g ZXhwZWN0YXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBTRVQgcHJv ZmlsZXMsIG5vciBzaG91bGQgdGhlcmUgYmU8L2I+LCBhcyB0aGVpciBhcHBsaWNhdGlvbnMgYXJl IGRpZmZlcmVudC4mbmJzcDsgVHJ5aW5nIHRvIG1ha2UgU0VUcyByZXF1aXJlIGNob2ljZXMgYXBw cm9wcmlhdGUgdG8gYSBwYXJ0aWN1bGFyIHByb2ZpbGUgd2lsbCBuZWNlc3NhcmlseSBtYWtlIHRo ZW0gYSBwb29yIG9yIGltcG9zc2libGUNCiBmaXQgZm9yIG90aGVycy4mbmJzcDsgVGhpcyB3b3Vs ZCBiZSBhIHZlcnkgYmFkIHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+SXJvbmljYWxseSwg4oCcbG9ja2luZyBkb3du4oCdIFNFVCB0byByZXF1aXJlIGNob2ljZXMg bW90aXZhdGVkIGJ5IGEgcGFydGljdWxhciBwcm9maWxlIHdvdWxkbuKAmXQgaGVscCB0aGF0IHBy b2ZpbGUgYXQgYWxsLCBhcyBpdCB3b3VsZCB3b3JrIHRoZSBzYW1lIHdoZXRoZXIgU0VUIHdhcyDi gJxsb2NrZWQgZG93buKAnSBvciBub3QuJm5ic3A7IEJ1dCBpdCB3b3VsZCB1bm5lY2Vzc2FyaWx5 DQogcHJlY2x1ZGUgdXNlIG9mIFNFVHMgaW4gb3RoZXIgY29udGV4dHMgdGhhdCB0aGV5IGFyZSBj dXJyZW50bHkgYSBncmVhdCBmaXQgZm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzptc2N1cnRlc2N1QGdvb2ds ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI2LCAyMDE3IDk6NDMgQU08 YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+ DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZn dDs7IFBoaWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7OyBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs7IEpvaG4gQnJhZGxleSAm bHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7OyBIZW5rIEJpcmtob2x6ICZsdDtoZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlJmd0OzsgWWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21h aWwuY29tJmd0OzsNCiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDtpZC1ldmVudEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElk L0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbiwgaW4gdGhlIGNhc2Ugd2hlbiBhbiBSUCBpcyBp c3N1aW5nIHRoZSBTRVQgdG8gc2VuZCBpdCB0byBhbiBJZFAsIGEgdG9wIGxldmVsIHN1YiBhcyB5 b3UgZGVzY3JpYmUgaXQgbWF5IG5vdCBiZSBwb3NzaWJsZS4gT3IgbWF5YmUgSSBtaXN1bmRlcnN0 YW5kLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYWdy ZWUgb24gJnF1b3Q7aXNzJnF1b3Q7IEkgdGhpbmssIGluIHRoaXMgY2FzZSBpdCBwb2ludHMgdG8g dGhlIFJQLiBBIHRvcCBsZXZlbCAmcXVvdDtzdWImcXVvdDsgdGhvdWdoIGlzIHByb2JsZW1hdGlj LCBUaGUgUlAgaW4gbWFueSBjYXNlcyBoYXMgdGhlIG9wYXF1ZSAmcXVvdDtzdWImcXVvdDsgYXMg aXNzdWVkIGJ5IHRoZSBJZFAsIGJ1dCB0aGlzIHZhbHVlIGlzIGdsb2JhbGx5IHVuaXF1ZSBvbmx5 IHdoZW4gY29tYmluZWQgd2l0aCB0aGUgSWRQICZxdW90O2lzcyZxdW90Oy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHN1cmUgd2h5IGV2 ZW50LmF1ZCB3b3VsZCBiZSBuZWNlc3Nhcnk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJpdXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEp1biAyNSwg MjAxNyBhdCA3OjMxIEFNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hl ckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPk1pa2UsIHRoaXMgaXMgbm90 IGF0IGFsbCB3aGF0IEkgc2VlIGZvciBoYXZpbmcgdGhlICZxdW90O21vc3Qgc3VwcG9ydCZxdW90 Oy4gSW5zdGVhZCBJJ20gc2VlaW5nIGEgbG90IG9mIGNhbGwgZm9yIGhhdmluZyAmcXVvdDtzdWIm cXVvdDsgZGVmaW5lZCBjbGVhcmx5IGluIHRoZSBldmVudCBwYXlsb2FkIG9ubHkuPG86cD48L286 cD48L3A+DQo8cD5UaGUgJnF1b3Q7c3ViJnF1b3Q7IG9mIHRoZSBtYWluIGJvZHkgaXMgdGhlIHN1 YmplY3QgYXMga25vd24gYnkgdGhlIGlzc3VlciBvZiB0aGUgU0VUIGl0c2VsZi4gVGhpcyBtaWdo dCBiZSB0aGUgc2FtZSBzdWJqZWN0IHRoYXQgdGhlIHN1YmplY3QgaXMga25vd24gYnkgYXQgdGhl IHRhcmdldCBvZiB0aGUgU0VULiBUaGVyZSBhcmUgbWFueSBjYXNlcyB3aGVyZSB0aGlzIGlzbid0 IHRydWUsIGFuZCBzbyBmYXIgb25lIGV4Y2VwdGlvbiBjYXNlIHdoZXJlIGl0IGlzLA0KIHNvbWV0 aW1lcy4gV2Ugc2hvdWxkIG5vdCBiZSB3cml0aW5nIHRoaXMgZm9yIHRoZSBleGNlcHRpb24uPG86 cD48L286cD48L3A+DQo8cD5CdXQgSSB0aGluayB0aGVyZSdzIGEgcHJldHR5IGNsZWFyIHBhdGgg Zm9yd2FyZC4gVGhlICZxdW90O3N1YiZxdW90OyBpbiB0aGUgYm9keSBvZiBhIFNFVCwgaWYgaXQg aXMgaW5jbHVkZWQsIGlzICpBTFdBWVMqIGluIHRoZSBjb250ZXh0IG9mIHRoZSAmcXVvdDtpc3Mm cXVvdDsgb2YgdGhlIFNFVC4gQWx3YXlzLCBmdWxsIHN0b3AsIG5vIGV4Y2VwdGlvbnMuIE5vIGds b2JhbCBuYW1lc3BhY2VzLCBubyByZXN0cmljdGlvbnMgb24gY29udGVudCwgbm8gZm9ybWF0cyAt LSBpdCdzDQogYW4gb3BhcXVlICh0byB0aGUgU0VUIHN0YW5kYXJkKSB2YWx1ZSBpbiB0aGUgZG9t YWluIG9mIHRoZSBpc3N1ZXIgb2YgdGhlIFNFVC4gPG86cD4NCjwvbzpwPjwvcD4NCjxwPkV2ZW50 IHBheWxvYWRzLCBkZWZpbmVkIGluIHByb2ZpbGVzLCBkZXNjcmliZSBhIHN1YmplY3Qgb2YgdGhl IGV2ZW50IGl0c2VsZi4gSW1wb3J0YW50bHksIHRoaXMgaXMgdGhlIHN1YmplY3QgYXMga25vd24g YnkgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIGV2ZW50IHdpbGwgYmUgKnJlY2VpdmVkKiwgbm90 IGluIHdoaWNoIGl0IHdhcyAqaXNzdWVkKi4gU29tZXRpbWVzIHRob3NlIGFyZSB0aGUgc2FtZSwg bW9yZSBvZnRlbiAoYXMgd2UncmUNCiBzZWVpbmcpIHdlIGNhbid0IGd1YXJhbnRlZSB0aGF0LiBX ZSBzaG91bGQgbm90IGRlcGVuZCBvbiB0aGF0IGFuZCB3ZSBzaG91bGQgbm90IHRyZWF0IHRoZSBl eGNlcHRpb25hbCBjYXNlIGFzIHRoZSB1c3VhbCwgbm8gbWF0dGVyIHdoYXQgc3ludGF4IGFub3Ro ZXIgZ3JvdXAgaGFzIGNvbWUgdXAgd2l0aC4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+U28gaGVyZSdz IHRoZSB0aGluZy4gSSB0aGluayB0aGUgJnF1b3Q7c3ViJnF1b3Q7IG9mIGFuIGV2ZW50IHNob3Vs ZCBiZSBvcHRpb25hbCwgYW5kIEFMV0FZUyBpbiB0aGUgY29udGV4dCBvZiB0aGUgaXNzdWVyLCBh bmQgcHJvZmlsZXMgc2hvdWxkIG5vdCBwbGFjZXMgZnVydGhlciBjb25zdHJhaW50cyBvbiB0aGF0 LiBFdmVudHMgdGhlbXNlbHZlcyBzaG91bGQgYmUgc2VsZi1jb250YWluZWQuIEkgcmVncmV0IHRo YXQgd2UgZGlkbid0IG1ha2UgdGhlIHJlZ2lzdHJhdGlvbg0KIG9iamVjdCBpbiBSRkM3NTkxIG1v cmUgc2VsZi1jb250YWluZWQsIGFzIHRoYXQncyBjYXVzZWQgaW1wbGVtZW50YXRpb24gYW5kIGV4 dGVuc2lvbiBpc3N1ZXMuIEkgdGhpbmsgZXZlbnRzIHNob3VsZCBhbHdheXMgaGF2ZSBhbiBpbnRl cm5hbCBzdWJqZWN0L2lzc3VlciBwYWlyLCBpbiB0aGUgY29udGV4dCBvZiB3aGVyZSB0aGUgZXZl bnQgaXMgYmVpbmcgY29uc3VtZWQuIFdlIG5lZWQgdG8gZGVmaW5lIHdoYXQgaXNzL3N1YiBtZWFu IChpbiBhIGdyYW5kDQogc2Vuc2UpIGluc2lkZSB0aGUgZXZlbnQgb2JqZWN0IGluIHRoaXMgZG9j dW1lbnQsIHNvIHRoYXQgZGlmZmVyZW50IGV2ZW50cyBkb24ndCByZWludmVudCB0aGUgc2FtZSB0 aGluZyBvdmVyIGFuZCBvdmVyLiBJZiBhIHByb2ZpbGUgd2FudHMgdG8gbGVhdmUgdGhhdCBvdXQg YmVjYXVzZSB0aGV5IGRvbid0IG5lZWQgYW4gaWRlbnRpZmllciBmb3IgdGhlIHBheWxvYWQsIHRo ZW4gdGhleSBjYW4gbGVhdmUgaXQgb3V0LiBJZiB0aGV5IHdhbnQgdG8gbGVhdmUNCiBpdCBvdXQg YmVjYXVzZSB0aGV5IHdhbnQgdG8gYXNzdW1lIHRoZXJlIHdpbGwgJnF1b3Q7YWx3YXlzJnF1b3Q7 IGJlIGFuIGlzcy9zdWIgaW4gdGhlIHJvb3Qgb2YgdGhlIFNFVCwgdGhlbiBJIGhhdmUgYSBwcm9i bGVtIHdpdGggdGhhdC4gVGhlIGlzc3VlciBvZiB0aGUgU0VUIGNhbiwgYW5kIHByb2JhYmx5IGRv ZXMsIGhhdmUgaXRzIG93biBpZGVudGlmaWVyIHdoaWNoIGNhbid0IGJlIGFzc3VtZWQgdG8gYmUg dW5pdmVyc2FsLiBQcm9wb3NpbmcgYSBnbG9iYWwgc3ViamVjdA0KIG5hbWVzcGFjZSBvciBmb3Jt YXQsIGFzIGhhcyBiZWVuIHN1Z2dlc3RlZCBlbHNld2hlcmUgb24gdGhpcyBsaXN0LCBpcyBsdWRp Y3JvdXMgYW5kIHdpbGwgbmV2ZXIgZmx5IGFzIGl0IGdvZXMgYWdhaW5zdCBob3cgSldUIG5hbWVz cGFjaW5nIGZvciBwZW9wbGUgYW5kIG9iamVjdHMgaGFzIGFsd2F5cyB3b3JrZWQuIFdlIHNob3Vs ZCBoYXZlIGEgY2xlYXIgc2VtYW50aWMgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjYW4gYmUgZXh0ZW5k ZWQgYW5kIHVzZWQNCiBieSBhbGwgb2YgdGhlIHVzZSBjYXNlcyB0aGF0IHdlJ3ZlIGFkb3B0ZWQu IE9wdGltaXppbmcgYXQgdGhpcyBzdGFnZSwgZXNwZWNpYWxseSBiYXNlZCBvbiBvbmUgZXZlbnQs IGlzIGdvaW5nIHRvIGp1c3QgbGVhZCB0byB0aGluZ3MgYmVpbmcgYnJva2VuIGFuZCBiYWNrLXBh dGNoZWQgbGF0ZXIgb24uIEJ1dCBpZiBvbmUgc3BlYyB3YW50cyB0byBsZWF2ZSBvdXQgdGhlIGlz cy9zdWIgaW5zaWRlIHRoZSBldmVudD8gVGhleSBjYW4gc3RpbGwgZG8NCiB0aGF0LCBidXQgSSB0 aGluayB0aGF0J3MgcHJldHR5IGRhZnQuPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwPkluIHN1bW1hcnk6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQppc3M6IGlzc3VlciBvZiB0aGUgZXZlbnQ8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0Kc3ViOiBzdWJqZWN0IG9mIHRoZSBldmVudCBhcyBrbm93biBieSB0aGUgaXNzdWVyIG9mIHRo ZSBldmVudDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpldmVudC5zdWI6IHN1YmplY3Qgb2YgdGhl IGV2ZW50IGFzIGtub3duIGJ5IHRoZSByZWNpcGllbnQgb2YgdGhlIGV2ZW50PG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCmV2ZW50LmlzczogY29udGV4dCBmb3IgdGhlIHN1YmplY3Qgb2YgdGhlIGV2 ZW50IGFzIGtub3duIGJ5IHRoZSByZWNpcGllbnQgb2YgdGhlIGV2ZW50PG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCmV2ZW50LmF1ZDogcmVjaXBpZW50IG9mIHRoZSBldmVudDxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD4mbmJzcDstLSBKdXN0aW48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYvMjEvMjAxNyA3OjQ1IFBNLCBNaWtlIEpv bmVzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBwcm9wb3NhbCB0aGF0IEkgYmVsaWV2ZSBoYXMgdGhlIG1vc3Qgc3VwcG9y dCBpcyBrZWVwaW5nIHRoaW5ncyBhcyB0aGV5IGFyZSwgbGVhdmluZyBpdCB1cCB0byBwcm9maWxl cyBhbmQgYXBwbGljYXRpb25zIHRvIGRlZmluZSB3aGljaCBjbGFpbXMgdGhleSB1c2UgYW5kIGhv dyB0aGV5IHVzZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgd291bGQgYmUg ZmluZSBmb3Igc29tZSBwcm9maWxlcyB0byB1c2UgdGhlIGxhbmd1YWdlIGJlbG93LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+4oCTIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbToNCjwvYj48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5QaGlsIEh1 bnQ8L2E+PGJyPg0KPGI+U2VudDogPC9iPldlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyA2OjM5IFBN PGJyPg0KPGI+VG86IDwvYj48YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlPC9hPjxicj4NCjxiPkNjOiA8 L2I+PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pk1hcml1cyBTY3VydGVzY3U8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t IiB0YXJnZXQ9Il9ibGFuayI+Sm9obiBCcmFkbGV5PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmhlbmsu Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj4NCkhlbmsgQmlya2hv bHo8L2E+OyA8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+ SnVzdGluIFJpY2hlcjwvYT47DQo8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+WWFyb24gU2hlZmZlcjwvYT47IDxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj4NCk1pa2UgSm9uZXM8L2E+ OyA8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JRCBF dmVudHMgTWFpbGluZyBMaXN0PC9hPjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50 XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VU IGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvIEkgdW5kZXJzdGFuZCB3aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGlzOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHRoZSBldmVudCB0eXBl IHVzZXMg4oCcc3Vi4oCdIHRvIGlkZW50aWZ5IGl0cyBzdWJqZWN0LCBhbmQgdGhlIGlzc3VlciBv ZiB0aGUgc3ViamVjdCBpcyBpZGVudGljYWwgdG8gdGhlIGlzc3VlciBmb3IgdGhlIGV2ZW50LCB0 aGVuIOKAnHN1YuKAnSBtYXkgYmUgdXNlZCBhdCB0aGUgdG9wIGxldmVsLiBPdGhlcndpc2UsIHRo ZSBzdWJqZWN0IG9mIGFuDQogZXZlbnQgKGUuZy4g4oCcc3Vi4oCdKSBhbmQgYW55IG90aGVyIGNs YWltcyByZXF1aXJlZCB0byB1bmlxdWVseSBpZGVudGlmeSB0aGUgc3ViamVjdCBNVVNUIGJlIGNv bnRhaW5lZCBpbiB0aGUgZXZlbnQgcGF5bG9hZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBhbiBpcCBhZGRy ZXNzIG9mIDEuMi4zLjQgbWlnaHQgYmUgcmVwcmVzZW50ZWQgaW4gYSDigJxpcGFkZHJlc3PigJ0g Y2xhaW0gZGVmaW5lZCBpbiB0aGUgZXZlbnQgcGF5bG9hZC4g4oCcaXBhZGRyZXNz4oCdOuKAnTEu Mi4zLjQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgU0NJTSByZXNvdXJjZSBVUkkgb2YgPGEgaHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1w bGUuY29tL3VzZXJzL2FjMWZhZWJiZmQzYzQ1Y2U5YTI0MmJkMzg1OWM4MmM0IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3NjaW0uZXhhbXBsZS5jb20vdXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlh MjQyYmQzODU5YzgyYzQ8L2E+IG1pZ2h0IGJlIGlkZW50aWZpZWQgaW4gdGhlIGV2ZW50IHBheWxv YWQgYXM6IOKAnHN1YuKAnTomcXVvdDs8YSBocmVmPSJodHRwczovL3NjaW0uZXhhbXBsZS5jb20v dXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5YzgyYzQiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3NjaW0uZXhhbXBsZS5jb20vdXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5 YzgyYzQ8L2E+4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkEgQ29ubmVjdCBMb2dvdXQgZXZlbnQgZnJvbSBhbiBPUCB1c2VzIHRoZSB0b3Ag bGV2ZWwgc3ViIGNsYWltIGFuZCBkZXBlbmRzIG9uIOKAnGlzc+KAnSBiZWluZyB0aGUgc2FtZSBm b3IgdGhlIGV2ZW50IGlzc3VlciBBTkQgdGhlIHN1YmplY3QuIFRoaXMgbWVhbnMgdGhhdCBubyBw YXJ0eSBtYXkgaXNzdWUgbG9nb3V0IGV2ZW50cyBvbiBiZWhhbGYgb2YgdGhlIE9QLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRl bnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0ICZhbXA7IFN0YW5kYXJkczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0iX2JsYW5r Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDIxLCAyMDE3LCBhdCAzOjM4IFBNLCBSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPkZhaXIgcG9pbnQuIElmIHdlIGRvIG5vdCBpbnRlbmQgdG8gc3VwcG9y dCBtdWx0aXBsZSBwcm9maWxlcyB3aXRoaW4gYSBzaW5nbGUgU0VULCB0aGVuIEnigJltIGxlc3Mg Y29uY2VybmVkIGFib3V0IGxlYXZpbmcgc3ViIHNlbWFudGljcyB1cCB0byB0aGUgcHJvZmlsZXMu PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1 MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3VydGVzY3VA Z29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQz Njg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldlZG5lc2Rh eSwgSnVuZSAyMSwgMjAxNyBhdCAyOjU4IFBNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9Im0tNjY1 Njk3Mjk0MzY4NTM0MjEyNWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4m cXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5yaWNoYW5uYUBhbWF6b24uY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90O1BoaWwgSHVudCAoSURN KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OywgSm9obiBCcmFkbGV5ICZsdDs8 YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJA dmU3anRiLmNvbTwvYT4mZ3Q7LA0KIEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvYT4mZ3Q7LCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVm PSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1 PC9hPiZndDssIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywN CiBNaWNoYWVsIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElk L0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5FeGFtcGxlIGZvciBtdWx0aXBsZSBl dmVudHMgd2l0aGluIHNhbWUgcHJvZmlsZTogSWRQIGFjY291bnQgaXMgZGlzYWJsZWQgKGJlY2F1 c2Ugb2YgaGlqYWNraW5nKSwgdGhpcyBjYW4gbGVhZCB0byB0d28gZXZlbnRzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4xLiAmcXVvdDthY2Nv dW50LWRpc2FibGVkJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Mi4gJnF1b3Q7c2Vzc2lvbnMtcmV2b2tlZCZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5NYXJpdXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPk9uIFdl ZCwgSnVuIDIxLCAyMDE3IGF0IDI6NTQgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZs dDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZn dDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZSBzcGVjIHNh eXMgdGhhdCB0aGUgZXZlbnRzIGNsYWltIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBleHByZXNzIG11 bHRpcGxlIGxvZ2ljYWwgZXZlbnRzLiBJZiBpdOKAmXMgYWxzbyBub3QgdXNlZCB0byBleHByZXNz IGV2ZW50cyBmcm9tIGRpZmZlcmVudCBwcm9maWxlcyB0aGF0IGNvcnJlc3BvbmQgdG8gdGhlIHNh bWUgbG9naWNhbCBldmVudCAoZS5nLiBhbiBPSURDDQogYmFja2NoYW5uZWwgbG9nb3V0IGV2ZW50 IGFsb25nc2lkZSBhIGh5cG90aGV0aWNhbCBSSVNDIGxvZ291dCBldmVudCksIHRoZW4gSeKAmW0g bm90IHN1cmUgd2hhdCB1c2UgY2FzZSB0aGF0IGxlYXZlcyBmb3IgbXVsdGlwbGUgZXZlbnRzIGlu IG9uZSBTRVQuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZu YnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0Ij5JZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxm IG9mICZxdW90O1BoaWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFu IGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+V2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IGF0IDI6MTIgUE08YnI+DQo8Yj5U bzo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPkpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0 YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ dmU3anRiQHZlN2p0Yi5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0i bS02NjU2OTcyOTQzNjg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZndDssIEhlbmsgQmly a2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVuay5iaXJraG9s ekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0OywNCiBKdXN0aW4gUmljaGVyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+anJpY2hlckBtaXQuZWR1PC9zcGFuPjwvYT4mZ3Q7LCBNYXJpdXMg U2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUu Y29tPC9zcGFuPjwvYT4mZ3Q7LCBZYXJvbg0KIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDssIE1pY2hhZWwgSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208L3NwYW4+PC9hPiZndDssDQogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0ibS02NjU2 OTcyOTQzNjg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJl OiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBk aXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5TZXBhcmF0ZSBvciBjb21iaW5lZCBtYXkgYmUgZXZvbHZpbmcuIE1pa2Ugd2FudHMgdG8g a2VlcCB0aGUgY3VycmVudCBiYWNrY2hhbm5lbCBsb2dvdXQgdmVyeSBuYXJyb3dseSBzY29wZWQu IEhlIHN1Z2dlc3RlZCByaXNjIGRlZmluZSBpdHMgb3duIGR1cGxpY2F0ZQ0KIGRlZmluaXRpb25z IGFuZCBtZWFuaW5ncy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV8tNjY1Njk3Mjk0MzY4NTM0MjEyNW1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhB cHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tNjY1Njk3Mjk0MzY4NTM0MjEyNW1f LTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U aGF0IGxlYWRzIG1lIHRvIGJlbGlldmUgd2Ugd2lsbCBoYXZlIG11bHRpLXR5cGUgZXZlbnRzIGlu IHByYWN0aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlk PSJtXy02NjU2OTcyOTQzNjg1MzQyMTI1bV8tNDYyOTg0MjU2OTM4NTE1OTk4OEFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy02NjU2OTcyOTQzNjg1MzQyMTI1bV8tNDYyOTg0MjU2 OTM4NTE1OTk4OEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNlc3Npb24gY2Fu Y2VsbGF0aW9uIGNhbiBvY2N1ciBmb3IgbWFueSByZWFzb25zLiBPbmUgb2YgdGhlIGRpZmZlcmVu dGlhdG9ycyB3ZSBoYWQgdHJpZWQgdG8gbWFrZSB3YXMgYW4gYXNzdW1wdGlvbiB0aGF0IHVzZXIg aW5pdGlhdGVkIGV2ZW50cyB3b3VsZA0KIGJlIHBhcnQgb2YgY29ubmVjdC4gUmlzayB3b3VsZCBj b3ZlciB2YXJpYXRpb25zIHRoYXQgZHJpdmUgb2ZmIG9mIHJpc2sgY2FsY3VsYXRpb25zIGxpa2Ug cGFzc3dvcmQgcmVzZXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1fLTY2NTY5NzI5NDM2ODUzNDIxMjVtXy00NjI5ODQyNTY5Mzg1MTU5OTg4 QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTY2NTY5NzI5NDM2ODUzNDIxMjVt Xy00NjI5ODQyNTY5Mzg1MTU5OTg4QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ VGhlcmUgYXJlIGFsc28gc2lnbm91dCBldmVudHMgYXQgcnAncyB0byBsZXQgdGhlIE9QIGtub3cu IFRoZXNlIGFyZSBub3QgY29tbWFuZHMgYnV0IG5vdGlmaWNhdGlvbiB0aGF0IGEgcmVzb3VyY2Ug c2Vzc2lvbiBpcyBjYW5jZWxsZWQuIElPVyBzaW5nbGUNCiBzaWduIG91dCBub3QgZXhwZWN0ZWQu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f LTY2NTY5NzI5NDM2ODUzNDIxMjVtXy00NjI5ODQyNTY5Mzg1MTU5OTg4QXBwbGVNYWlsU2lnbmF0 dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0K T24gSnVuIDIxLCAyMDE3LCBhdCAxOjU4IFBNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1h aWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnZlN2p0YkB2ZTdqdGIuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkkgdGhvdWdo dCB3ZSBkZWNpZGVkIHRoYXQgd2UgYXJlIG9ubHkgYWxsb3dpbmcgc2V0IG1lc3NhZ2VzIGZvcm0g dGhlIHNhbWUgZmFtaWx5IHRoYXQgYWdyZWUgb24gdG9wIGxldmVsIGNsYWltcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ T3RoZXJ3aXNlIHRoZXJlIGNhbiBiZSBubyB0b3AgbGV2ZWwgY2xhaW1zIGFuZCB3ZSBhcmUgcmVh bGx5IGRlZmluaW5nIGEgYWx0ZXJuYXRpdmUgZm9ybWF0IHRvIEpXVCBpbiBzb21lIHdheXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Sm9obiBCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gSnVuIDIxLCAyMDE3LCBh dCAzOjU0IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJpY2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SSBhZ3JlZSB3aXRoIEpvaG4g dGhhdCB0aGUgSldUIHR5cGUgY29uZnVzaW9uIHByb2JsZW0gYW5kIHRoZSBTRVQgc3ViIHByb2Js ZW0gY2FuIGFuZCBzaG91bGQgYmUgZGlzY3Vzc2VkIHNlcGFyYXRlbHkuIFRoZSBzZWNldmVudHMg V0cgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCBzZXR0aW5nIHRvIGRpc2N1c3MgdGhlIGZvcm1l ci48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5NeSBjb25jZXJuIHdpdGggdGhlIHN1YiBjbGFpbSBpcyB0aGF0 IHR3byBwcm9maWxlcyBtYXkgZGljdGF0ZSBjb25mbGljdGluZyBzZW1hbnRpY3MgKGUuZy4gUHJv ZmlsZSBBIHNheXMgaXTigJlzIGEgcGhvbmUgbnVtYmVyLCBQcm9maWxlIEIgc2F5cyBpdOKAmXMg YW4gZW1haWwgYWRkcmVzcykuIElmIHRoZXNlIHByb2ZpbGVzIGRvbuKAmXQgcHJvdmlkZSBhbiBh bHRlcm5hdGUNCiB3YXkgdG8gZGVjbGFyZSBzdWJqZWN0IG9mIHRoZWlyIGV2ZW50cywgdGhlbiB0 aGV5IGNhbm5vdCBiZSBwcmVzZW50IHdpdGhpbiB0aGUgc2FtZSB0b2tlbi4gVGhpcyBpbmNvbXBh dGliaWxpdHkgdHJhcCBzZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGVhc2lseSBt aXNzZWQgYnkgZ3JvdXBzIHByb2ZpbGluZyBTRVQuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJt LTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQiPkpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dmU3anRiQHZlN2p0Yi5j b208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2 ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+V2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IGF0IDE6MzkgUE08YnI+DQo8Yj5U bzo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5 ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkp1 c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qcmljaGVyQG1pdC5lZHU8L3NwYW4+ PC9hPiZndDssIE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1 QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5t c2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDssDQogQW5uYWJlbGxlIFJpY2hhcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+ Jmd0OywgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiBNaWNoYWVsIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4m Z3Q7LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1l dmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OywNCiBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVm PSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIu ZGU8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5 NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tl biBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SW4gdGhlIGVudmVsb3Bl IHR5cCBpcyBhIG1lZGlhL21pbWUgdHlwZS4mbmJzcDsgUmVnaXN0ZXJpbmcgYXBwbGljYXRpb24v aWR0JiM0Mztqd3QgaWYgd2UgcmVnaXN0ZXIgand0IGFzIGEgc3RydWN0dXJlZCBuYW1lIHN1Zml4 LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Vc2luZyB0aGUgY3R5 IGlzIGFsc28gcG9zc2libGUuICZuYnNwOyBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgd2hhdCBpcyBi ZXR0ZXIgYnV0IHdlIGNhbiBhZ3JlZSBvbiBhIGNvbnZlbnRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Tm90IGV2ZXJ5dGhpbmcgaXMgZ29pbmcg dG8gYmUgYSBzZXQgdG9rZW4gbGlrZSBub3QgZXZlcnkgSldTIGlzIGEgSldULjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgd2UgYXJlIGdvaW5nIHRvIGRlZmlu ZSBwcm9jZXNzaW5nIHJ1bGVzIHRvIHN0b3AgY29sbGlzaW9ucyBhbmQgY29uZnVzaW9uIGFyb3Vu ZCBKV1QgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcywgd2Ugc2hvdWxkIGp1c3Qgc3RhcnQgdXNpbmcg dGhlIHR5cA0KIHBhcmFtZXRlciBiYXNlZCBvbiB0aGUgZXhpc3Rpbmcgc3BlYy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGdlbmVyYWwgY29udGVudCBzbmlm ZmluZyBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIG9wdGlvbiBldmVudHVhbGx5IGdldHMgeW91 IGludG8gdHJvdWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IGZvcmNpbmcgdGhlcmUgdG8gYmUgbm8gc3ViIGF0IHRo ZSB0b3AgbGV2ZWwgaXMgYSBnb29kIGlkZWEuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgbm90IHRoZSB3YXkgd2Ugc2hvdWxkIGRpZmZlcmVu dGlhdGUgYmV0d2VlbiBTRVQgYW5kIGlkX3Rva2Vucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+SWYgc3ViIGlzIG5vdCBhbGxvd2VkIGF0IHRoZSB0b3AgbGV2ZWwgcGVv cGxlIHdpbGwgZG8gbm9uIFNFVCBKV1QgZm9yIHRoaW5ncyB3aGVyZSB0aGUgc3ViamVjdCBpcyBz Y29wZWQgdG8gdGhlIGlzcyBvZiB0aGUgdG9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+SSB0aGluayBkZWZpbmluZyBzdWIgdG8gYmUgcGFydCBvZiB0 aGUgZXZlbnQgZm9yIGNhc2VzIHdoZXJlIHRoZSBzdWIgaXMgc2NvcGVkIGRpZmZlcmVudGx5IGZy b20gdGhlIGlzc3VlciBvZiB0aGUgdG9rZW4gaXMgZmluZSwgYnV0IHNob3VsZCBub3QNCiBiZSBy ZXF1aXJlZCBmb3IgYWxsIGV2ZW50IHR5cGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPkkgdGhpbmsgd2Ugc2hvdWxkIHNvbHZlIHRoZSBjb25mdXNpb24g aXNzdWUgc2VwYXJhdGVseSBmcm9tIHRoZSBzdWIgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+U29ycnkgSSBhbSBhdCBDSVMgc28gdHJ5aW5nIHRv IGNhdGNoIHVwIG9uIGxpc3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkpvaG4gQi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIEp1biAxNywgMjAxNywgYXQgMzo0NSBQTSwgWWFyb24gU2hlZmZlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0 Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIHRvIHN1bW1h cml6ZSB3aGF0IEknbSBzZWVpbmcgb24gdGhpcyB0aHJlYWQ6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkV2ZXJ5Ym9keSBhZ3JlZXMg d2l0aCBNYXJpdXMncyBzaG9ydC10ZXJtIHNvbHV0aW9uLCBzcGVjaWZpYyBydWxlcyBmb3IgJnF1 b3Q7c3ViJnF1b3Q7IGFuZCAmcXVvdDtpc3MmcXVvdDsgdGhhdCBjYW4gYmUgZGVmaW5lZCBpbiB0 aGUgU0VUIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9uZy10ZXJtICZx dW90O3VzYWdlJnF1b3Q7IGNsYWltICgmcXVvdDt0eXBlJnF1b3Q7IGlzIHRha2VuKSB0aGF0IHNo b3VsZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJDUC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RGlkIEkg bWlzcyBhbnl0aGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+QnkgdGhlIHdheSwgaWYgd2UgZG8gYWRkIGEgJnF1b3Q7dXNhZ2Um cXVvdDsgY2xhaW0sIHdlIG5lZWQgdG8gYWxzbyB1c2UgaXQgaW4gdGhlIFNFVCBkb2N1bWVudCBi ZWZvcmUgaXQgaXMgcHVibGlzaGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBZ YXJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmljaGVy IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+JiM0MzsxIHRvIHRoaXMgYXMgd2VsbC48c3BhbiBjbGFzcz0i bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPk9uIEp1biAxNSwgMjAxNywgYXQgMTowOSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0 Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiYjNDM7MSB0byB3 aGF0IEFubmFiZWxsZSBzYWlkLjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2 Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BbHNvLCBNaWtlIHlvdSBhcmUgbWlzc2lu ZyB0aGUgb3RoZXIgcmVxdWlyZW1lbnQsIGZvciBSUHMgdG8gc2VuZCBldmVudHMgdG8gYW4gSWRQ LiBUaGUgaXNzJiM0MztzdWIgcGFpciBhdCB0aGUgdG9wIGxldmVsIGlzIGJyb2tlbiBpbiB0aGlz IGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+TWFyaXVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9u IFdlZCwgSnVuIDE0LCAyMDE3IGF0IDU6MzMgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDsNCiB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTY2NTY5NzI5NDM2ODUzNDIxMjVtXy00NjI5ODQyNTY5 Mzg1MTU5OTg4bV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTY2NTY5NzI5NDM2ODUzNDIxMjVtXy00NjI5ODQyNTY5 Mzg1MTU5OTg4bV85MDk0MDg5MjM5NjY4NTcwMzEyQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEp1biAxNCwgMjAxNywgYXQgNToyNSBQTSwgUmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cmljaGFubmFA YW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+TWlrZSw8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNw OzxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPllvdXIgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGlzIGlzIGEgbm9uLXByb2Js ZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3RzIG9mIGVsZW1lbnRzIG9mIE9wZW5JRCBD b25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4gQXMgYSBy ZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGggaXQ6PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtLTY2NTY5NzI5 NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xp c3RwYXJhZ3JhcGgiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4NCjEuPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9Im0tNjY1 Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5UaGUgY2FsbGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBp cyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBjZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElE DQogVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFydHkgdGhhdCB0aGUgY2FsbGVy IHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkgdG8gdmVyaWZ5IGl0cyBwcm92 ZW5hbmNlLjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhtOTA5NDA4OTIzOTY2 ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4NCjIuPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5BbnkgZnV0dXJlIElEIFRva2VuIGRp c3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJtLTY2NTY5NzI5 NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xp c3RwYXJhZ3JhcGgiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQiPjMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1 NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+Tm8g b3RoZXIgcHJvZmlsZSBvZiBKV1QgY2FuIGV2ZXIgdXNlIHRoZSAmcXVvdDtub25jZeKAnSBjbGFp bS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibS02 NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkwOTQwODkyMzk2Njg1NzAz MTJtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0Ij40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00 NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPlRoaXMgaXMgb25seSBhIHNvbHV0aW9uIGZvciBJRCBUb2tlbnMuIEV2ZXJ5IG90aGVyIEpX VA0KIHByb2ZpbGUgdGhhdCBjYXJlcyBhYm91dCBkaXNhbWJpZ3VhdGlvbiBoYXMgdG8gaW52ZW50 IGl0cyBvd24gc29sdXRpb24gdG8gdGhlIHByb2JsZW0uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPldlIGtub3cgZnJv bSBleHBlcmllbmNlIHRoYXQgbmFtaW5nIGNvbGxpc2lvbnMgYW5kIHJlcGxheSBhdHRhY2tzIGFy ZSBib3RoIHRoaW5ncyB0aGF0IGhhcHBlbi4gV2hhdOKAmXMgYmVpbmcgcHJvcG9zZWQgaXMgYSBz aW1wbGUsIGRlZmVuc2l2ZSBtZWFzdXJlIGFnYWluc3QgdGhlc2Ugcmlza3MuIFlvdSBicm91Z2h0 IHVwIEpXVCBsaWJyYXJpZXM6IGEgZ2VuZXJhbCBzb2x1dGlvbg0KIGFjdHVhbGx5IG1ha2VzIGl0 IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJhcmllcyBmb3IgSldUIHBhcnNpbmcuIEEg4oCcdXNh Z2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQgaGFuZGxlIGRpc2FtYmlndWF0aW9uIGZvciBh bnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aCB0aGUgc3RhdHVzIHF1byBlYWNoIHByb2ZpbGUg d291bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00 NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5JZC1ldmVudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7DQogb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1Njkz ODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5 LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibS02NjU2 OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzpt c2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8 c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90O1JpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFt YXpvbi5jb208L3NwYW4+PC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nDQogTGlzdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssIEhlbmsg Qmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVy LmRlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlv biBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojMDAyMDYwIj5Zb3XigJl2ZSBoZWFy ZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiZuYnNwOyBJ4oCZZCBjaGFyYWN0ZXJp emUgdGhlIHByb3Bvc2FscyBpbiB0aGlzIHRocmVhZCBhcyDigJxwcmVtYXR1cmUgcGVzc2ltYXRp b27igJ0g4oCTIG1ha2luZyB0aGluZ3MgdGhhdCBjYW4gYW5kIHNob3VsZCBiZSBzaW1wbGUgY29t cGxleCwNCiB3aXRob3V0IGRhdGEgc2hvd2luZyB0aGVyZeKAmXMgYW55IG5lZWQgdG8gZG8gc28u PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtjb2xvcjojMDAyMDYwIj5NYW5kYXRvcnkgc29sdXRpb25zIGFyZSBiZWluZyBwcm9wb3NlZCBp biB0aGlzIHRocmVhZCB0byBwcm9ibGVtcyB0aGF0IHRoZXJl4oCZcyBubyBldmlkZW5jZSB0aGF0 IHdlIGFjdHVhbGx5IGV2ZW4gaGF2ZS4mbmJzcDsgSXTigJlzIGFscmVhZHkgYmVlbiBlc3RhYmxp c2hlZCB0aGF0IGl04oCZcyBpbXBvc3NpYmxlDQogZm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZv ciBhbiBJRCBUb2tlbiDigJMgc2VlPHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0t NDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9pZC0yRGV2ZW50X2N1cnJlbnRfbXNn MDA0MjguaHRtbCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTEx NWMmYW1wO3M9ZUtMVFFQbVlyVjNUaGZEYm45MFNDczU1VVJPVFBpbl9sZ2M2UmRyNVhvdyZhbXA7 ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRt bDwvc3Bhbj48L2E+LiZuYnNwOw0KIElmIHBlb3BsZSBoYXZlIGRhdGEgc2hvd2luZyB0aGF0IHRo aXMgaXMgcG9zc2libGUgd2l0aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9rZW5zIG9yIG90 aGVyIHJlYWwgSldUIGRlcGxveW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZpY3MsIHNvIHRo YXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEgdG8gaW5mb3JtIGFwcHJvcHJpYXRlIGVuZ2luZWVyaW5n IGNob2ljZXMgb24gb3VyIHBhcnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojMDAyMDYwIj5UaGUgcHJvcG9zZWQg4oCcc29s dXRpb25z4oCdLCBzdWNoIGFzIHByb2hpYml0aW5nIHRoZSB1c2Ugb2Yg4oCcc3Vi4oCdIGluIHRo ZSBub3JtYWwgd2F5LCBvciByZXF1aXJpbmcgYSB0eXBlIGNsYWltLCB3b3VsZCBtYWtlIHByZXZp b3VzbHkgc2ltcGxlIHRoaW5ncyB1bm5lY2Vzc2FyaWx5IGNvbXBsZXguJm5ic3A7DQogWWVzLCB0 aGVuIHRoZSByZXN1bHQgaXMgdGhlbiBkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCBKV1QgYnV0IGEg Y29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJzaW5nIGNvZGUgd291bGQgaGF2 ZSB0byBiZSB1c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpXVCBwYXJzZXIuJm5ic3A7IFRo ZSBtb3JlIHVud2llbGR5IHdlIG1ha2UgaXQgdG8gdXNlIFNFVHMsIHRoZSBtb3JlIGxpa2VseSBk ZXZlbG9wZXJzIGFyZSB0byBqdXN0IGNyZWF0ZQ0KIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMu Jm5ic3A7IEtlZXBpbmcgaXQgc2ltcGxlIGlzIHRoZSBrZXkgdG8gYWRvcHRpb24uJm5ic3A7IFN0 YW5kYXJkcyBhcmUgb25seSB1c2VmdWwgaWYgdGhleSBhcmUgYWN0dWFsbHkgdXNlZC48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiMwMDIwNjAiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYy OTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklkLWV2 ZW50IFs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0t NDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi Pk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0 MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SaWNo YXJkIEJhY2ttYW4sIEFubmFiZWxsZTxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJtLTY2 NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE08YnI+DQo8Yj5U bzo8L2I+PHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1 OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1hcml1cyBTY3VydGVzY3Ug Jmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+ PC9hPiZndDs7IEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6 QHNpdC5mcmF1bmhvZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0Ozxicj4N CjxiPkNjOjwvYj48c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5 Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SUQgRXZlbnRzIE1h aWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3Nw YW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQz Njg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25m dXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj5FY2hvaW5nIE1hcml1c+KAmXMgcXVlc3Rpb246IGNhbiB5b3UgZXhw bGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnGludGVuZOKAnT88c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPlRvIHlvdXIgZmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3 b3VsZCBiZSB0aGUgWC41MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJv cGVydHkgdGhhdCBkZWNsYXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBhbmQg dGhhdCBhIHJlY2lwaWVudCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZw0KIHdoZXRoZXIg dG8gYWNjZXB0IGEgSldUIGJlaW5nIHByZXNlbnRlZCB0byBpdCBpbiBzb21lIGNvbnRleHQuPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZGVudGl0eSBTZXJ2aWNlczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+RnJvbTo8c3BhbiBjbGFz cz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0Ij5JZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxmIG9mIE1hcml1cyBT Y3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5j b208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2 ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+VHVlc2RheSwgSnVuZSAxMywgMjAxNyBhdCAxMTowNSBBTTxicj4NCjxiPlRv OjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+SGVuayBCaXJraG9seiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1 bmhvZmVyLmRlPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9Im0tNjY1Njk3 Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5JRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWls dG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBzb2x1 dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vl cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gVHVlLCBKdW4gMTMs IDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsu Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9zcGFuPjwvYT4m Z3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QW5kIGEgMm5kIHF1ZXN0aW9uLjxicj4NCjxicj4NCldoYXQgc2VtYW50aWNzIHdv dWxkICZxdW90O3VzYWdlJnF1b3Q7IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2 aWEgJnF1b3Q7aW50ZW5kJnF1b3Q7LCAmcXVvdDthdWRpZW5jZSZxdW90OywgYW5kICZxdW90O3Nj b3BlJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O2F1ZCZxdW90OyAoYXVkaWVuY2UpIHNwZWNpZmllcyB0 aGUgdGFyZ2V0IGNsaWVudCwgYnV0IG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgKGFjY2VzcyB0b2tl biB0byBhdXRob3JpemUgcmVzb3VyY2UgYWNjZXNzIG9yIFNFVCB0byBjb21tdW5pY2F0ZSBhIHNl Y3VyaXR5DQogZXZlbnQ/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7c2NvcGUmcXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SSBkb24ndCBrbm93IHdoYXQgZG8geW91IG1lYW4gYnkgJnF1b3Q7aW50ZW5kJnF1b3Q7IChvciBp bnRlbnQpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpIZW5rPGJyPg0K PGJyPg0KT24gMDYvMTMvMjAxNyAwMTowMSBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhPGJyPg0KPGJyPg0KSSB0aGluayB0 aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQgaW4gMy45IGFyZSBmbGF3ZWQ6PGJyPg0KPGJyPg0KwrdX ZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11 dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1l dGVycywgYW5kIGVuZm9yY2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29n bml6ZWQgY2xhaW3igJ0gYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0 dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0YWtlbiBmb3IgSldUcw0KIGZyb20gYSBjdXJyZW50IHNw ZWMuPGJyPg0KPGJyPg0KwrdJdCBpcyB1bnJlYWxpc3RpYyB0byBleHBlY3QgaW1wbGVtZW50ZXJz IHRvIGFkaGVyZSB0byB0aGUg4oCcZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVudCBraW5kcyBv ZiBKV1Rz4oCdIHJ1bGUuIFdoZXRoZXIgbWFuZGF0ZWQgYnkgdGhlIHNwZWMgb3Igbm90LCBpbXBs ZW1lbnRlcnMgd2lsbCBpZ25vcmUgdGhpcyBiZWNhdXNlIG1hbmFnaW5nIG9uZSBrZXkgaXMgZWFz aWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZmZXJlbnQga2V5cy48YnI+DQo8YnI+DQrCt0RpdHRvIGZv ciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBjbGFpbXMuPGJyPg0KPGJyPg0KJiM0MzsxIGZvciBh IOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci48YnI+DQo8 YnI+DQotLTxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUx NTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpBbm5h YmVsbGUgUmljaGFyZCBCYWNrbWFuPGJyPg0KPGJyPg0KSWRlbnRpdHkgU2VydmljZXM8YnI+DQo8 YnI+DQoqRnJvbTogKklkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnQtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlk LWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgb24gYmVoYWxmIG9mIERpY2sg SGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9z cGFuPjwvYT4mZ3Q7PGJyPg0KKkRhdGU6ICpNb25kYXksIEp1bmUgMTIsIDIwMTcgYXQgMzoxOCBQ TTxicj4NCipUbzogKk1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRl c2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQoqQ2M6ICpBZGFtIERh d2VzICZsdDs8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+ Jmd0OywgJnF1b3Q7bWF0YWtlLCBub3YmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpub3ZAbWF0 YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bm92QG1h dGFrZS5qcDwvc3Bhbj48L2E+Jmd0OywgSUQgRXZlbnRzIE1haWxpbmcNCiBMaXN0ICZsdDs8YSBo cmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OywgJnF1b3Q7 UGhpbCBIdW50IChJRE0pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCipTdWJqZWN0OiAqUmU6IFtJZC1ldmVu dF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNF VCBpc3N1ZXI8YnI+DQo8YnI+DQpBZ3JlZWQuIE5vdGUgdGhhdCB0aGVyZSBpcyBzdGlsbCBsb3Rz IG9mIGRpc2N1c3Npb24gb24gd2hhdCBzaG91bGQgYmUgaW4gMy45Ljxicj4NCjxicj4NCk9uIE1v biwgSnVuIDEyLCAyMDE3IGF0IDM6MTUgUE0sIE1hcml1cyBTY3VydGVzY3UgJmx0OzxhIGhyZWY9 Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L3NwYW4+PC9hPiZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48 L2E+Jmd0OyZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoYW5rcyBmb3Ig dGhlIHBvaW50ZXIgRGljaywgdmVyeSBnb29kIHRpbWluZyA6LSk8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IFRoZSBpc3N1ZSBpcyBkZXNjcmliZWQgYnkgJnF1b3Q7Mi43LiBDcm9zcy1KV1QgQ29u ZnVzaW9uJnF1b3Q7IGFuZCB0aGU8YnI+DQombmJzcDsgJm5ic3A7IG1pdGlnYXRpb24gaXMgaW4g JnF1b3Q7My45LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZlIFZhbGlkYXRpb24gUnVsZXMgZm9yPGJy Pg0KJm5ic3A7ICZuYnNwOyBEaWZmZXJlbnQgS2luZHMgb2YgSldUcyZxdW90Oywgc3BlY2lmaWNh bGx5ICZxdW90O1VzZSBkaWZmZXJlbnQgc2V0cyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgcmVxdWly ZWQgY2xhaW1zLi4uJnF1b3Q7LCAmcXVvdDtVc2UgZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVu dCBraW5kcyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgSldUcy4mcXVvdDsgYW5kICZxdW90O1VzZSBk aWZmZXJlbnQgaXNzdWVycyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHMuJnF1b3Q7Ljxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgSSBzdGlsbCB0aGluayB0aGF0IGEgJnF1b3Q7dHlwZSZxdW90 OyBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFuZDxicj4NCiZuYnNwOyAmbmJz cDsgc2FmZXR5Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgTWFyaXVzPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6NTkgUE0sIERpY2sgSGFy ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFu PjwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1 Ymxpc2hlZCBhbiBCQ1AgSUQgZm9yIEpXVDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fc2VsZi0yRGlzc3VlZC5pbmZv Xy0zRnAtM0QxNjkwJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2Fp MTE1YyZhbXA7cz1hN1h2WjVqVGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9z ZWxmLWlzc3VlZC5pbmZvLz9wPTE2OTA8L3NwYW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6MDIgUE0gQWRhbSBEYXdl cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhd2VzQGdvb2dsZS5jb208L3NwYW4+PC9hPjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzphZGF3ZXNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmFkYXdlc0Bnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHdhcyBpbml0 aWFsbHkgYSBmYW4gb2Yga2VlcGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkIHRva2VucyBidXQgSSBu b3cgdGhpbmsgdGhpcyBpcyBhIGJldHRlciBwbGFuLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQ TSBtYXRha2UsIG5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ub3ZAbWF0YWtlLmpwPC9zcGFuPjwv YT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+bm92QG1hdGFrZS5qcDwvc3Bhbj48L2E+Jmd0OyZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOzEgZXNwZWNpYWxseSBmb3IgJnF1b3Q7dHlwZSZxdW90Ozxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgMjAxNy0wNi0wOSAxMDozMiBHTVQmIzQzOzA5OjAwIFBoaWwgSHVudCAoSURNKTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwv YT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9zcGFuPjwvYT4mZ3Q7Jmd0Ozo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBoaWw8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyBPbiBKdW4gOCwgMjAxNywgYXQgNjoyOCBQTSwgTWFyaXVzIFNjdXJ0ZXNjdTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29v Z2xlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48 L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSB3ZXJlIGEgY291cGxlIG9mIHByb3Bvc2FscyBvbiBo b3cgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlzdGluZ3Vpc2ggU0VUcyBmcm9tIElkIFRva2VucyBh bmQgQWNjZXNzIFRva2VucyBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdWNoIGEgd2F5IHRoYXQgbmFp dmUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbmZ1c2Ugb25l IGZvciB0aGUgb3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdnVs bmVyYWJpbGl0aWVzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsgVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVu dDogdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJl IGRpZmZlcmVudCBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzdWImcXVvdDsgaXNz dWVyLiBUaGlzIGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcgU0VUczxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB0byBhbiBJZFAuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9z ZSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9sbG93aW5nOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IC0gYm90aCAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0byBiZSBk ZWZpbmVkIGF0IHRoZSBldmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZXZlbDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0 b3AgU0VUIGxldmVsIGNhbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBkaWZmZXJlbnQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O2lzcyZxdW90OyBhbmQgJnF1b3Q7c3ViJnF1b3Q7 IGF0IGV2ZW50IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWNyb3Nz IGV2ZW50cyBpbiB0aGUgc2FtZSBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZx dW90O3N1YiZxdW90OyBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBTRVQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFz ZSBub3RlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3Nob3VsZCZxdW90OyBhbmQgbm90ICZxdW90 O211c3QmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7IFRoaXMgc29sdXRpb24gYWxzbyBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVz IHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRp dGlvbmFsIGNsYWltczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFp bCBvciBwaG9uZV9udW1iZXIpIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaW5jZSBhbGwgdGhlc2Ug Y2xhaW1zIHdpbGwgYmUgYXQgdGhlIGV2ZW50IGxldmVsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJl IHdpbGwgYmUgbm8gY29sbGlzaW9ucyBvciBhbWJpZ3VpdHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBBbm90aGVyIHByb3Bvc2FsICh3 aGljaCBJIHN1cHBvcnRlZCkgd2FzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlZmluZSBhIGNvbXBv c2l0ZSAmcXVvdDthdWQmcXVvdDsgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmc8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0Jm5ic3A7IFNFVCBpc3N1ZXIu IEFsc28sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGhhdmluZyB0aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmlu ZyBkaWZmZXJlbnQgc3ludGF4PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIGRpZmZlcmVudCB0b2tlbiB0 eXBlcyBjb3VsZCBsZWFkIHRvIGNvbmZ1c2lvbi48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3 YXMgdG8gaW50cm9kdWNlIGEgbmV3PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNsYWltIGZvciBKV1RzIHRo YXQgZGVmaW5lcyBhICZxdW90O3R5cGUmcXVvdDsuIFRoaXMgaXMgbm90PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHByYWN0aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwgYW5kIGl0IGFsc28gaXMgbm90PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHNvbHZpbmcgdGhlIGRpc3RpbmN0IGlzc3VlciByZXF1aXJlbWVudCwgYnV0 IEkgdGhpbms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhpcyBpcyBzb21ldGhpbmcgdGhlIEpXVCBncm91 cCBzaG91bGQgc2VyaW91c2x5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNpZGVyLjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhvdWdodHM/ PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyBNYXJpdXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8c3Bh biBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVt LTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4m bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3Bh biBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smYW1wO209Sm11dXRCeDREQVBwNzRBVUxjeDJJX2p2Z1h6dWE2bWlS aUhxV2dmeHFtZyZhbXA7cz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxo eFdJJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1 Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVM Y3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1wO3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBu ODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT08L3NwYW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3Bh biBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVt LTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4m bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEy NW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01H YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0Za WVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQy MTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bh bj48L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQy NTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2ht UWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xE NEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQ8L3NwYW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0tPHNwYW4gY2xhc3M9Im0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0 MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFkYW0gRGF3ZXMgfCBTci4g UHJvZHVjdCBNYW5hZ2VyIHw8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNAZ29vZ2xlLmNvbTwv c3Bhbj48L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNAZ29vZ2xlLmNvbTwvc3Bhbj48 L2E+Jmd0OyB8PGEgaHJlZj0idGVsOiUyQjElMjA2NTAtMjE0LTI0MTAiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mIzQzOzEgNjUwLTIxNC0yNDEwPC9zcGFuPjwv YT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEg aHJlZj0idGVsOiUyODY1MCUyOSUyMDIxNC0yNDEwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+dGVsOig2NTApJTIwMjE0LTI0MTA8L3NwYW4+PC9hPiZndDs8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im0t NjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3Jn PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5 Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im0t NjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQt MkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZ VHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRD X2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMm YW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS08c3BhbiBjbGFzcz0ibS02NjU2OTcyOTQzNjg1 MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YnNjcmliZSB0byB0aGUg SEFSRFRXQVJFICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdq NzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWk3NVV3OGFlaFl2bHBJWk5MN054cUd4aGgx VE9yUU9VWDJYTVlCZXJWODAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cDovL2hhcmR0d2FyZS5jb20vPC9zcGFuPjwvYT4mZ3Q7DQogbWFpbCBs aXN0IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYXJuIGFib3V0IHByb2pl Y3RzIEkgYW0gd29ya2luZyBvbiE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLTxzcGFuIGNsYXNz PSJtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRU V0FSRSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJ VFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhD c0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFP VVgyWE1ZQmVyVjgwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvc3Bhbj48L2E+Jmd0Ow0KIG1haWwgbGlzdCB0 byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVu dEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpq V3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pS b2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dz JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJ VFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhD c0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3 b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4 QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3 bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZh bXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5 ZzdvTVU3VG1HTVNXV3MmYW1wO2U9PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtL WTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smYW1wO209bC1PODJOTEktYjhRRGwyUTlUa3BWb2JRejNoXzRUeUJHQXE1cGZac09jdyZhbXA7 cz0wTFdSbEdUSXFpVHNEaG1IdVJJQjUtUlJmdDgyQzcyOS1QRVlKaEx1NVNRJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXBvc2l0aW9uOmlu aXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFs IGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj5JZC1ldmVudCBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTti YWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0 aWFsIGluaXRpYWwiPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZh bXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFt cDttPWwtTzgyTkxJLWI4UURsMlE5VGtwVm9iUXozaF80VHlCR0FxNXBmWnNPY3cmYW1wO3M9MExX UmxHVElxaVRzRGhtSHVSSUI1LVJSZnQ4MkM3MjktUEVZSmhMdTVTUSZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtL WTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smYW1wO209bC1PODJOTEktYjhRRGwyUTlUa3BWb2JRejNoXzRUeUJHQXE1cGZac09jdyZhbXA7 cz0wTFdSbEdUSXFpVHNEaG1IdVJJQjUtUlJmdDgyQzcyOS1QRVlKaEx1NVNRJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBp ZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smYW1wO209bC1PODJOTEktYjhRRGwyUTlUa3BWb2JRejNoXzRUeUJHQXE1cGZa c09jdyZhbXA7cz0wTFdSbEdUSXFpVHNEaG1IdVJJQjUtUlJmdDgyQzcyOS1QRVlKaEx1NVNRJmFt cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB05045836B0610DDAD95B0039F5DF0CY4PR21MB0504namp_-- From nobody Mon Jun 26 10:13:43 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A48129C0E for ; Mon, 26 Jun 2017 10:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlBOLqo6XAxx for ; Mon, 26 Jun 2017 10:13:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95231292FD for ; Mon, 26 Jun 2017 10:13:35 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5QHDPpt008215 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 17:13:26 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5QHDOqi016584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jun 2017 17:13:25 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5QHDMxO015613; Mon, 26 Jun 2017 17:13:23 GMT Received: from [192.168.1.25] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jun 2017 10:13:22 -0700 From: Phil Hunt Message-Id: <24D916AE-D446-4302-9903-612C296BDD64@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B635381-F5AB-4C1F-8EB4-51D618E794C0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Jun 2017 10:13:20 -0700 In-Reply-To: Cc: Justin Richer , Marius Scurtescu , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Yaron Sheffer , ID Events Mailing List To: Mike Jones References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:13:41 -0000 --Apple-Mail=_4B635381-F5AB-4C1F-8EB4-51D618E794C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 26, 2017, at 10:05 AM, Mike Jones = wrote: >=20 > Justin, > =20 > The rules you=E2=80=99re proposing may be fine for a SET profile for a = particular kind of application. I encourage you to join the RISC = working group and work on them there. But they would limit the use = cases that SETs could be used for, which would be unfortunate and = unnecessary. > =20 > An analogy with JWT is illustrative. JWT is intentionally = general-purpose, leaving it up to application profiles what claims to = use and what their semantics are. This enables JWTs to be used for ID = Tokens = and also for completely unrelated uses, = such as SIP = = and Caller ID = . There is no expectation of interoperability = between these different JWT applications. Indeed =E2=80=93 both the = syntax *and the semantics*, such has how to determine what keys are = valid, are different. It=E2=80=99s this flexibility that makes JWTs = general-purpose. > =20 > Likewise, SET as currently specified is similarly general-purpose. = Application profiles define what SET claims to use and their semantics. = There is no expectation of interoperability between different SET = profiles, nor should there be, as their applications are different. = Trying to make SETs require choices appropriate to a particular profile = will necessarily make them a poor or impossible fit for others. This = would be a very bad thing. -1 is not a strong enough expression here. The whole point of this WG is to have a comment message and transfer = format. Each profile can define events of different meaning but to have = JWT processing that is dramatically different and complex would be a = negative outcome that kills the value of this working group. If people find the need to extend messaging protocols (e.g. to introduce = things like complex error signalling). They are not doing events right. If this is truly the WG decision, we are back to RISC specific, SCIM = specific, Session specific, OAuth specific event protocols and formats. = Yet many participants will all have these systems interconnected to our = security systems which are all evolving over time. Having 5 or 6 = connectors coupled with inconsistent implementation leads us no-way. It = means we will not be communicating with each other to help our customers = unless we pay the high costs of custom connectors and cross-license each = silo=E2=80=99s proprietary API. The whole point of a standard is to make this possible, not to create a = barrier to security. Lack of common inter-op between systems and silos is a HUGE loss. This is also the lesson learned from TAXII. They did not have a strong = standard and it failed because there is no implementable common = platform. > =20 > Ironically, =E2=80=9Clocking down=E2=80=9D SET to require choices = motivated by a particular profile wouldn=E2=80=99t help that profile at = all, as it would work the same whether SET was =E2=80=9Clocked down=E2=80=9D= or not. But it would unnecessarily preclude use of SETs in other = contexts that they are currently a great fit for. > =20 > -- = Mike > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Monday, June 26, 2017 9:43 AM > To: Justin Richer > Cc: Mike Jones ; Phil Hunt = ; Richard Backman, Annabelle = ; John Bradley ; Henk Birkholz = ; Yaron Sheffer = ; ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Justin, in the case when an RP is issuing the SET to send it to an = IdP, a top level sub as you describe it may not be possible. Or maybe I = misunderstand. > =20 > We agree on "iss" I think, in this case it points to the RP. A top = level "sub" though is problematic, The RP in many cases has the opaque = "sub" as issued by the IdP, but this value is globally unique only when = combined with the IdP "iss". > =20 > Not sure why event.aud would be necessary? >=20 > Marius > =20 > On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer > wrote: > Mike, this is not at all what I see for having the "most support". = Instead I'm seeing a lot of call for having "sub" defined clearly in the = event payload only. >=20 > The "sub" of the main body is the subject as known by the issuer of = the SET itself. This might be the same subject that the subject is known = by at the target of the SET. There are many cases where this isn't true, = and so far one exception case where it is, sometimes. We should not be = writing this for the exception. >=20 > But I think there's a pretty clear path forward. The "sub" in the body = of a SET, if it is included, is *ALWAYS* in the context of the "iss" of = the SET. Always, full stop, no exceptions. No global namespaces, no = restrictions on content, no formats -- it's an opaque (to the SET = standard) value in the domain of the issuer of the SET.=20 >=20 > Event payloads, defined in profiles, describe a subject of the event = itself. Importantly, this is the subject as known by the context in = which the event will be *received*, not in which it was *issued*. = Sometimes those are the same, more often (as we're seeing) we can't = guarantee that. We should not depend on that and we should not treat the = exceptional case as the usual, no matter what syntax another group has = come up with. >=20 > So here's the thing. I think the "sub" of an event should be optional, = and ALWAYS in the context of the issuer, and profiles should not places = further constraints on that. Events themselves should be self-contained. = I regret that we didn't make the registration object in RFC7591 more = self-contained, as that's caused implementation and extension issues. I = think events should always have an internal subject/issuer pair, in the = context of where the event is being consumed. We need to define what = iss/sub mean (in a grand sense) inside the event object in this = document, so that different events don't reinvent the same thing over = and over. If a profile wants to leave that out because they don't need = an identifier for the payload, then they can leave it out. If they want = to leave it out because they want to assume there will "always" be an = iss/sub in the root of the SET, then I have a problem with that. The = issuer of the SET can, and probably does, have its own identifier which = can't be assumed to be universal. Proposing a global subject namespace = or format, as has been suggested elsewhere on this list, is ludicrous = and will never fly as it goes against how JWT namespacing for people and = objects has always worked. We should have a clear semantic data = structure that can be extended and used by all of the use cases that = we've adopted. Optimizing at this stage, especially based on one event, = is going to just lead to things being broken and back-patched later on. = But if one spec wants to leave out the iss/sub inside the event? They = can still do that, but I think that's pretty daft. >=20 > =20 >=20 > In summary: >=20 > iss: issuer of the event > sub: subject of the event as known by the issuer of the event > event.sub: subject of the event as known by the recipient of the event > event.iss: context for the subject of the event as known by the = recipient of the event > event.aud: recipient of the event > =20 >=20 > -- Justin >=20 > =20 > On 6/21/2017 7:45 PM, Mike Jones wrote: > The proposal that I believe has the most support is keeping things as = they are, leaving it up to profiles and applications to define which = claims they use and how they use them. > =20 > It would be fine for some profiles to use the language below. > =20 > =E2=80=93 Mike > From: Phil Hunt > Sent: Wednesday, June 21, 2017 6:39 PM > To: Richard Backman, Annabelle > Cc: Marius Scurtescu ; John Bradley = ; Henk Birkholz = ; Justin Richer = ; Yaron Sheffer ; = Mike Jones ; ID Events Mailing List = > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > So I understand what is being proposed is: > =20 > If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, = and the issuer of the subject is identical to the issuer for the event, = then =E2=80=9Csub=E2=80=9D may be used at the top level. Otherwise, the = subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims = required to uniquely identify the subject MUST be contained in the event = payload. > =20 > For example, an ip address of 1.2.3.4 might be represented in a = =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. = =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4" > A SCIM resource URI of = https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 = might = be identified in the event payload as: = =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a24= 2bd3859c82c4 = =E2=80=9D= > =20 > A Connect Logout event from an OP uses the top level sub claim and = depends on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND = the subject. This means that no party may issue logout events on behalf = of the OP. > =20 > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com = > phil.hunt@oracle.com > =20 > On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle = > wrote: > =20 > Fair point. If we do not intend to support multiple profiles within a = single SET, then I=E2=80=99m less concerned about leaving sub semantics = up to the profiles. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Marius Scurtescu > > Date: Wednesday, June 21, 2017 at 2:58 PM > To: "Richard Backman, Annabelle" > > Cc: "Phil Hunt (IDM)" >, John Bradley >, Henk Birkholz = >, Justin Richer = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Example for multiple events within same profile: IdP account is = disabled (because of hijacking), this can lead to two events: > 1. "account-disabled" > 2. "sessions-revoked" >=20 > Marius > =20 > On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle = > wrote: > The spec says that the events claim SHOULD NOT be used to express = multiple logical events. If it=E2=80=99s also not used to express events = from different profiles that correspond to the same logical event (e.g. = an OIDC backchannel logout event alongside a hypothetical RISC logout = event), then I=E2=80=99m not sure what use case that leaves for multiple = events in one SET. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event > on behalf of "Phil Hunt (IDM)" = > > Date: Wednesday, June 21, 2017 at 2:12 PM > To: John Bradley > > Cc: "Richard Backman, Annabelle" >, Henk Birkholz = >, Justin Richer = >, Marius Scurtescu = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Separate or combined may be evolving. Mike wants to keep the current = backchannel logout very narrowly scoped. He suggested risc define its = own duplicate definitions and meanings.=20 > =20 > That leads me to believe we will have multi-type events in practice. > =20 > Session cancellation can occur for many reasons. One of the = differentiators we had tried to make was an assumption that user = initiated events would be part of connect. Risk would cover variations = that drive off of risk calculations like password reset.=20 > =20 > There are also signout events at rp's to let the OP know. These are = not commands but notification that a resource session is cancelled. IOW = single sign out not expected.=20 >=20 > Phil >=20 > On Jun 21, 2017, at 1:58 PM, John Bradley > wrote: >=20 > I thought we decided that we are only allowing set messages form the = same family that agree on top level claims. > =20 > Otherwise there can be no top level claims and we are really defining = a alternative format to JWT in some ways. > =20 > John B. > =20 > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle = > wrote: > =20 > I agree with John that the JWT type confusion problem and the SET sub = problem can and should be discussed separately. The secevents WG is = probably not the right setting to discuss the former. > =20 > My concern with the sub claim is that two profiles may dictate = conflicting semantics (e.g. Profile A says it=E2=80=99s a phone number, = Profile B says it=E2=80=99s an email address). If these profiles don=E2=80= =99t provide an alternate way to declare subject of their events, then = they cannot be present within the same token. This incompatibility trap = seems like something that could be easily missed by groups profiling = SET. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: John Bradley > > Date: Wednesday, June 21, 2017 at 1:39 PM > To: Yaron Sheffer > > Cc: Justin Richer >, Marius = Scurtescu >, = Annabelle Richard >, = Phil Hunt >, Michael = Jones >, ID Events Mailing List = >, Henk Birkholz = > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > In the envelope typ is a media/mime type. Registering = application/idt+jwt if we register jwt as a structured name sufix. =20 > =20 > Using the cty is also possible. I need to think about what is better = but we can agree on a convention. > =20 > Not everything is going to be a set token like not every JWS is a JWT. > =20 > If we are going to define processing rules to stop collisions and = confusion around JWT for different purposes, we should just start using = the typ parameter based on the existing spec. > =20 > In general content sniffing if there is more than one option = eventually gets you into trouble. > =20 > I am not convinced that forcing there to be no sub at the top level is = a good idea. =20 > =20 > It is not the way we should differentiate between SET and id_tokens. > =20 > If sub is not allowed at the top level people will do non SET JWT for = things where the subject is scoped to the iss of the token. > =20 > I think defining sub to be part of the event for cases where the sub = is scoped differently from the issuer of the token is fine, but should = not be required for all event types. > =20 > I think we should solve the confusion issue separately from the sub = issue. > =20 > Sorry I am at CIS so trying to catch up on lists. > =20 > John B. > =20 > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer > wrote: > =20 > So to summarize what I'm seeing on this thread: > Everybody agrees with Marius's short-term solution, specific rules for = "sub" and "iss" that can be defined in the SET spec. > Almost everybody agrees on a long-term "usage" claim ("type" is taken) = that should be defined elsewhere, e.g. in the JWT BCP. > Did I miss anything? > By the way, if we do add a "usage" claim, we need to also use it in = the SET document before it is published. > Thanks, > Yaron > =20 > On 15/06/17 22:08, Justin Richer wrote: > +1 to this as well.=20 > =20 > =E2=80=94 Justin > =20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > =20 > +1 to what Annabelle said.=20 > =20 > Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >=20 > Marius > =20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > +1 > =20 > Phil > =20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: > Mike, > =20 > Your explanation for why this is a non-problem is dependent upon side = effects of elements of OpenID Connect that were not designed to solve = this issue. As a result, I see several issues with it: > 1. The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance. >=20 > 2. Any future ID Token distribution method needs to solve this = problem again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile = that cares about disambiguation has to invent its own solution to the = problem. >=20 > =20 > We know from experience that naming collisions and replay attacks are = both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event > on behalf of Mike Jones = > > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > > Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematur= e pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. > =20 > Mandatory solutions are being proposed in this thread to problems that = there=E2=80=99s no evidence that we actually even have. It=E2=80=99s = already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that = this is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. > =20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use = of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, = would make previously simple things unnecessarily complex. Yes, then = the result is then different than a normal JWT but a consequence of this = is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu >; Henk Birkholz = > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Echoing Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D? > =20 > To your first question, I think a better analogy would be the X.509 = Key Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event > on behalf of Marius Scurtescu = > > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"? > =20 > "aud" (audience) specifies the target client, but not the intended = usage (access token to authorize resource access or SET to communicate a = security event?) > =20 > "scope" is not used by SET. > =20 > I don't know what do you mean by "intend" (or intent)? > =20 > =20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event > on behalf of Dick Hardt = > > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > > *Cc: *Adam Dawes >, = "matake, nov" >, ID Events Mailing = List >, "Phil Hunt (IDM)" = > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be = in 3.9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = >> wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > >> = wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 = >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > >> wrote: >=20 > I was initially a fan of keeping SETS to be very similar = to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > >> wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >>: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > >> wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens = in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: = the > SET issuer in some cases must be different from = the > "sub" issuer. This is the case of an RP sending = SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the = event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be = different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please = note > "should" and not "must" > > > > This solution also allows different profiles = that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not = solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I = think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org = > > > > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com = > > |+1 = 650-214-2410 > > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Subscribe to the HARDTWARE > mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_4B635381-F5AB-4C1F-8EB4-51D618E794C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 26, 2017, at 10:05 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Justin,
 
The rules = you=E2=80=99re proposing may be fine for a SET profile for a particular = kind of application.  I encourage you to join the RISC working = group and work on them there.  But they would limit the use cases = that SETs could be used for, which would be unfortunate and = unnecessary.
 
An analogy = with JWT is illustrative.  JWT is intentionally general-purpose, = leaving it up to application profiles what claims to use and what their = semantics are.  This enables JWTs to be used for ID = Tokens and also = for completely unrelated uses, such as SIP and Caller ID.  = There is no expectation of interoperability between these different JWT = applications.  Indeed =E2=80=93 both the syntax *and = the semantics*, such has how to determine what keys are valid, are = different.  It=E2=80=99s this flexibility that makes JWTs = general-purpose.
 
Likewise, = SET as currently specified is similarly general-purpose.  = Application profiles define what SET claims to use and their = semantics.  There is no expectation of interoperability between different = SET profiles, nor should there be, as their applications are = different.  Trying to make SETs require choices appropriate to a = particular profile will necessarily make them a poor or impossible fit = for others.  This would be a very bad = thing.

-1 = is not a strong enough expression here.

The whole point of this WG is to have a comment = message and transfer format.  Each profile can define events of = different meaning but to have JWT processing that is dramatically = different and complex would be a negative outcome that kills the value = of this working group.

If people = find the need to extend messaging protocols (e.g. to introduce things = like complex error signalling). They are not doing events = right.

If this is truly the WG = decision, we are back to RISC specific, SCIM specific, Session specific, = OAuth specific event protocols and formats.  Yet many participants = will all have these systems interconnected to our security systems which = are all evolving over time.  Having 5 or 6 connectors coupled with = inconsistent implementation leads us no-way. It means we will not be = communicating with each other to help our customers unless we pay the = high costs of custom connectors and cross-license each silo=E2=80=99s = proprietary API.

The whole point of = a standard is to make this possible, not to create a barrier to = security.

Lack of common inter-op = between systems and silos is a HUGE loss.

This is also the lesson learned from TAXII. =  They did not have a strong standard and it failed because there is = no implementable common platform.

 
Ironically, = =E2=80=9Clocking down=E2=80=9D SET to require choices motivated by a = particular profile wouldn=E2=80=99t help that profile at all, as it = would work the same whether SET was =E2=80=9Clocked down=E2=80=9D or = not.  But it would unnecessarily preclude use of SETs in other = contexts that they are currently a great fit for.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Marius Scurtescu [mailto:mscurtescu@google.com] 
Sent: Monday, June 26, 2017 9:43 = AM
To: Justin Richer <jricher@mit.edu>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt <phil.hunt@oracle.com>; Richard Backman, Annabelle = <richanna@amazon.com>; John Bradley <ve7jtb@ve7jtb.com>; = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Yaron Sheffer <yaronf.ietf@gmail.com>; ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for = Id/Access Token confusion and distinct SET issuer
 
Justin, in the case when an RP is issuing the SET to send it = to an IdP, a top level sub as you describe it may not be possible. Or = maybe I misunderstand.
 
We agree on "iss" I think, in this case it points to the RP. = A top level "sub" though is problematic, The RP in many cases has the = opaque "sub" as issued by the IdP, but this value is globally unique = only when combined with the IdP "iss".
 
Not sure why event.aud would be = necessary?

Marius
 
On Sun, Jun 25, 2017 at 7:31 AM, Justin = Richer <jricher@mit.edu> wrote:

Mike, this is not at all what I = see for having the "most support". Instead I'm seeing a lot of call for = having "sub" defined clearly in the event payload only.

The "sub" of the main body is the = subject as known by the issuer of the SET itself. This might be the same = subject that the subject is known by at the target of the SET. There are = many cases where this isn't true, and so far one exception case where it = is, sometimes. We should not be writing this for the exception.

But I think there's a pretty clear = path forward. The "sub" in the body of a SET, if it is included, is = *ALWAYS* in the context of the "iss" of the SET. Always, full stop, no = exceptions. No global namespaces, no restrictions on content, no formats = -- it's an opaque (to the SET standard) value in the domain of the = issuer of the SET. 

Event payloads, defined in profiles, = describe a subject of the event itself. Importantly, this is the subject = as known by the context in which the event will be *received*, not in = which it was *issued*. Sometimes those are the same, more often (as = we're seeing) we can't guarantee that. We should not depend on that and = we should not treat the exceptional case as the usual, no matter what = syntax another group has come up with.

So here's the thing. I think the "sub" of an event should be = optional, and ALWAYS in the context of the issuer, and profiles should = not places further constraints on that. Events themselves should be = self-contained. I regret that we didn't make the registration object in = RFC7591 more self-contained, as that's caused implementation and = extension issues. I think events should always have an internal = subject/issuer pair, in the context of where the event is being = consumed. We need to define what iss/sub mean (in a grand sense) inside = the event object in this document, so that different events don't = reinvent the same thing over and over. If a profile wants to leave that = out because they don't need an identifier for the payload, then they can = leave it out. If they want to leave it out because they want to assume = there will "always" be an iss/sub in the root of the SET, then I have a = problem with that. The issuer of the SET can, and probably does, have = its own identifier which can't be assumed to be universal. Proposing a = global subject namespace or format, as has been suggested elsewhere on = this list, is ludicrous and will never fly as it goes against how JWT = namespacing for people and objects has always worked. We should have a = clear semantic data structure that can be extended and used by all of = the use cases that we've adopted. Optimizing at this stage, especially = based on one event, is going to just lead to things being broken and = back-patched later on. But if one spec wants to leave out the iss/sub = inside the event? They can still do that, but I think that's pretty = daft.

 

In summary:

  • iss: issuer of the = event
  • sub: subject of the event as known by the issuer of the = event
  • event.sub: subject of the event as known by the recipient = of the event
  • event.iss: context for the subject of the event as = known by the recipient of the event
  • event.aud: recipient of the event

 

 -- Justin

 
On 6/21/2017 7:45 PM, Mike Jones wrote:
The proposal that I believe has the most support is keeping = things as they are, leaving it up to profiles and applications to define = which claims they use and how they use them.
 
It would = be fine for some profiles to use the language below.
 
=E2=80=93 = Mike
From: Phil Hunt
Sent: Wednesday, June 21, = 2017 6:39 PM
To: Richard Backman, = Annabelle
Cc: Marius = Scurtescu; John Bradley; Henk = Birkholz; Justin Richer; Yaron Sheffer; Mike = Jones; ID Events Mailing = List
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
So I understand what is being proposed = is:
 
If the event type uses =E2=80=9Csub=E2=80=9D to = identify its subject, and the issuer of the subject is identical to the = issuer for the event, then =E2=80=9Csub=E2=80=9D may be used at the top = level. Otherwise, the subject of an event (e.g. =E2=80=9Csub=E2=80=9D) = and any other claims required to uniquely identify the subject MUST be = contained in the event payload.
 
For example, an ip address of 1.2.3.4 = might be represented in a =E2=80=9Cipaddress=E2=80=9D claim defined in = the event payload. =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=  might be = identified in the event payload as: =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4= =E2=80=9D
 
A Connect Logout event from an OP uses the top level sub = claim and depends on =E2=80=9Ciss=E2=80=9D being the same for the event = issuer AND the subject. This means that no party may issue logout events = on behalf of the OP.
 
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect & = Standards
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Jun 21, 2017, at 3:38 = PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
 
Fair point. If we do not intend to support multiple profiles = within a single SET, then I=E2=80=99m less concerned about leaving sub = semantics up to the profiles.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: <= /b>Marius Scurtescu <mscurtescu@google.com>
Date: Wedn= esday, June 21, 2017 at 2:58 PM
To: "Ric= hard Backman, Annabelle" <richanna@amazon.com>
Cc: "Phi= l Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>,= Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, = Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>
Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Example for multiple events within same = profile: IdP account is disabled (because of hijacking), this can lead = to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
The spec says = that the events claim SHOULD NOT be used to express multiple logical = events. If it=E2=80=99s also not used to express events from different = profiles that correspond to the same logical event (e.g. an OIDC = backchannel logout event alongside a hypothetical RISC logout event), = then I=E2=80=99m not sure what use case that leaves for multiple events = in one SET.
 
-- 
Annabelle Richard = Backman
Identity Services
 
 
From: <= /b>Id-event <id-event-bounces@ietf.org> on behalf of "Phil = Hunt (IDM)" <phil.hunt@oracle.com>Date: Wedn= esday, June 21, 2017 at 2:12 PM
To: John= Bradley <ve7jtb@ve7jtb.com>
Cc: "Ric= hard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer = <jricher@mit.edu>, Marius Scurtescu = <mscurtescu@google.com>, = Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing = List <id-event@ietf.org>

Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Separate or combined may be evolving. = Mike wants to keep the current backchannel logout very narrowly scoped. = He suggested risc define its own duplicate definitions and = meanings. 
 
That leads me to believe we will have = multi-type events in practice.
 
Session cancellation can occur for = many reasons. One of the differentiators we had tried to make was an = assumption that user initiated events would be part of connect. Risk = would cover variations that drive off of risk calculations like password = reset. 
 
There are also signout events at rp's = to let the OP know. These are not commands but notification that a = resource session is cancelled. IOW single sign out not = expected. 

Phil


On Jun 21, 2017, at 1:58 PM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:

I thought we decided that we are only = allowing set messages form the same family that agree on top level = claims.
 
Otherwise there can be no top level claims = and we are really defining a alternative format to JWT in some ways.
 
John B.
 
On Jun 21, 2017, at 3:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
I agree with John that the JWT type = confusion problem and the SET sub problem can and should be discussed = separately. The secevents WG is probably not the right setting to = discuss the former.
 
My = concern with the sub claim is that two profiles may dictate conflicting = semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B = says it=E2=80=99s an email address). If these profiles don=E2=80=99t = provide an alternate way to declare subject of their events, then they = cannot be present within the same token. This incompatibility trap seems = like something that could be easily missed by groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From:=  John = Bradley <ve7jtb@ve7jtb.com>
Date:=  Wednesday, June 21, 2017 at 1:39 PM
To:=  Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=  Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle = Richard <richanna@amazon.com>, = Phil Hunt <phil.hunt@oracle.com>, = Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing = List <id-event@ietf.org>, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
In the envelope typ is a media/mime = type.  Registering application/idt+jwt if we register jwt as a = structured name sufix.  
 
Using the cty is also possible. =   I need to think about what is better but we can agree on a = convention.
 
Not everything is going = to be a set token like not every JWS is a JWT.
 
If we are going to define processing = rules to stop collisions and confusion around JWT for different = purposes, we should just start using the typ parameter based on the = existing spec.
 
In general content sniffing if there = is more than one option eventually gets you into trouble.
 
I am not convinced that forcing there = to be no sub at the top level is a good idea.  
 
It is not the way we should = differentiate between SET and id_tokens.
 
If sub is not allowed at the top level = people will do non SET JWT for things where the subject is scoped to the = iss of the token.
 
I think defining sub to be part of the = event for cases where the sub is scoped differently from the issuer of = the token is fine, but should not be required for all event types.
 
I think we should solve the confusion = issue separately from the sub issue.
 
Sorry I am at CIS so trying to catch up = on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 = PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
So to summarize what I'm = seeing on this thread:
Everybody agrees with Marius's = short-term solution, specific rules for "sub" and "iss" that can be = defined in the SET spec.
Almost everybody agrees on a long-term "usage" = claim ("type" is taken) that should be defined elsewhere, e.g. in the = JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we = need to also use it in the SET document before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, Justin Richer = wrote:
+1 to this as well.=  
 
 =E2=80=94 Justin
 
On Jun 15, 2017, at 1:09 = PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what Annabelle = said.=  
 
Also, Mike you are missing the other = requirement, for RPs to send events to an IdP. The iss+sub pair at the = top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> = wrote:
+1
 
Phil
 
On Jun 14, 2017, at 5:25 = PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
 
Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with it:

1.      =  The caller of the Token Endpoint is the only party = that can be certain that a nonce-less ID Token is really an ID Token. = Any party that the caller passes the ID Token off to has no way to = verify its provenance.

2.      =  Any future ID Token distribution method needs to = solve this problem again.

3.     =  No other profile of JWT can ever use the "nonce=E2=80=9D= claim.

4.     =  This is only a solution for ID Tokens. Every other = JWT profile that cares about disambiguation has to invent its own = solution to the problem.

 
We = know from experience that naming collisions and replay attacks are both = things that happen. What=E2=80=99s being proposed is a simple, defensive = measure against these risks. You brought up JWT libraries: a general = solution actually makes it easier to use common libraries for JWT = parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From:=  Id-event <id-event-bounces@ietf.org> on behalf of Mike = Jones <Michael.Jones@microsoft.com>
Date:=  Wednesday, June 14, 2017 at 1:16 PM
To:=  Marius Scurtescu <mscurtescu@google.com>
Cc:=  "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events = Mailing List <id-event@ietf.org>, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
You=E2=80=99ve heard of =E2=80=9Cpremature = optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in = this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making = things that can and should be simple complex, without data showing = there=E2=80=99s any need to do so.
 
Mandatory solutions are being proposed in this thread to = problems that there=E2=80=99s no evidence that we actually even = have.  It=E2=80=99s already been established that it=E2=80=99s = impossible for a SET to be confused for an ID Token =E2=80=93 see=  https://www.ietf.org/mail-archive/web/id-event/current/msg00428= .html.  If people have data showing that this is = possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part.
 
The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting = the use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type = claim, would make previously simple things unnecessarily complex.  = Yes, then the result is then different than a normal JWT but a = consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.  The more unwieldy we make it to = use SETs, the more likely developers are to just create their own data = structures.  Keeping it simple is the key to adoption.  = Standards are only useful if they are actually used.
 
          &nb= sp;            = ;            &= nbsp;            = -- Mike
 
From:=  Id-event [mailto:id-event-bounces@ietf.org]=  On Behalf Of=  Richard Backman, Annabelle
Sent:=  Tuesday, June 13, 2017 5:33 PM
To:=  Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:=  ID Events Mailing List <id-event@ietf.org>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer
 
Echoing Marius=E2=80=99s question: can you explain what you = mean by =E2=80=9Cintend=E2=80=9D?
 
To = your first question, I think a better analogy would be the X.509 Key = Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From:=  Id-event <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date:=  Tuesday, June 13, 2017 at 11:05 AM
To:=  Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:=  ID Events Mailing List <id-event@ietf.org>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.

What = semantics would "usage" provide that that are not covered via "intend", = "audience", and "scope"?
 
"aud" (audience) specifies the target = client, but not the intended usage (access token to authorize resource = access or SET to communicate a security event?)
 
"scope" is not used by SET.
 
I don't know what do you mean by = "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every = type of JWT will have a mutually exclusive set of valid claims and/or = header parameters, and enforcing this requires a =E2=80=9Cfail on an = unrecognized claim=E2=80=9D approach to ensure that JWTs from some = future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers = to adhere to the =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80= =9D rule. Whether mandated by the spec or not, implementers will ignore = this because managing one key is easier than managing N different = keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D = and =E2=80=9Ciss=E2=80=9D claims.

+1 for a = =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter.

--=  

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick = Hardt <dick.hardt@gmail.com>*Date: *Monday, June 12, 2017 at 3:18 PM
*To: = *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam = Dawes <adawes@google.com>, = "matake, nov" <nov@matake.jp>, ID = Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

Agreed. = Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius = Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, = very good timing :-)

    The = issue is described by "2.7. Cross-JWT Confusion" and the
    mitigation is in "3.9. Use Mutually Exclusive = Validation Rules for
    Different Kinds of = JWTs", specifically "Use different sets of
    = required claims...", "Use different keys for different kinds of
    JWTs." and "Use different issuers for different = kinds of JWTs.".

    I still = think that a "type" claim would bring a lot of clarity and
    safety.


    Marius

  =   On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
  =   <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I = just published an BCP ID for JWT
      =  =  http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM = Adam Dawes <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I = was initially a fan of keeping SETS to be very similar to
            id tokens but I now = think this is a better plan.

    =         On Thu, Jun 8, 2017 at 6:56 PM matake, nov = <nov@matake.jp
    =         <mailto:nov@matake.jp>> wrote:

                +1 = especially for "type"

      =           2017-06-09 10:32 GMT+09:00 Phil Hunt = (IDM)
              =   <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

            =         +1

  =                   Phil


        =              > On Jun 8, 2017, at = 6:28 PM, Marius Scurtescu
        =             <mscurtescu@google.com
      =               <mailto:mscurtescu@google.com>> wrote:
                =      >
        =              > There were a couple = of proposals on how to
          =           distinguish SETs from Id Tokens and = Access Tokens in
            =         such a way that naive implementations will = not
              =       confuse one for the other and open up security
                =     vulnerabilities.
        =              >
  =                   =  > There is also another important requirement: the
                =     SET issuer in some cases must be different from the
                =     "sub" issuer. This is the case of an RP sending SETs
                =     to an IdP.
        =              >
  =                   =  > With these requirements in mind I propose the
                =     following:
        =              > - both "sub" and = "iss" to be defined at the event
      =               level
                =      > - "iss" at event level and at top SET level = can
              =       be different
      =                > - "iss" and = "sub" at event level can be different
      =               across events in the = same SET
              =        > - "sub" should NOT be present at the top = SET
              =       level (this solves the disambiguation), please = note
              =       "should" and not "must"
    =                  >
                =      > This solution also allows different profiles = that
              =       define event types to define additional claims
                =     related to sub (like email or phone_number) and
                =     since all these claims will be at the event level
                =     there will be no collisions or ambiguity.
                =      >
        =              > Another proposal = (which I supported) was to
        =             define a composite "aud" = claim. This is not solving
        =             the requirement for a = distinct  SET issuer. Also,
      =               having the same claim = name having different syntax
        =             in different token types could = lead to confusion.
          =            >
  =                   =  > And yet another proposal was to introduce a new
                =     claim for JWTs that defines a "type". This is not
                =     practical in the short term, and it also is not
                =     solving the distinct issuer requirement, but I think
                =     this is something the JWT group should seriously
                =     consider.
          =            >
  =                   =  > Thoughts?
          =            >
  =                   =  > Marius

      =                > = _______________________________________________
  =                   =  > Id-event mailing list
                =      >=  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =                  >
                =    =  https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6= Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                =     _______________________________________________
                =     Id-event mailing list
      =              =  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =                =  https://www.ietf.org/mailman/listinfo/id-event

            =     _______________________________________________
                = Id-event mailing list
          =      =  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =            =  https://www.ietf.org/mailman/listinfo/id-event

            = --=  
            = Adam Dawes | Sr. Product Manager |adawes@google.com
    =         <mailto:adawes@google.com> |+1 650-214-2410
  =           <tel:(650)%20214-2410>

            = _______________________________________________
  =           Id-event mailing list
           =  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =        =  https://www.ietf.org/mailman/listinfo/id-event

        --=  
        Subscribe to the = HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working = on!



--=  

Subscribe to the HARDTWARE = <http://hardtware.com/> mail list to learn about = projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
<= div class=3D"">
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
 
_______________________________________________Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 

= --Apple-Mail=_4B635381-F5AB-4C1F-8EB4-51D618E794C0-- From nobody Mon Jun 26 10:14:16 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00361292FD for ; Mon, 26 Jun 2017 10:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQrSkR7iWu34 for ; Mon, 26 Jun 2017 10:14:09 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0581129BC4 for ; Mon, 26 Jun 2017 10:14:08 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id h134so4503901iof.2 for ; Mon, 26 Jun 2017 10:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9gFYBrbf8YicLDWxzYBg4XLOYGuO28YsBTMKDArBJGg=; b=c1d2mMEs7nwJ/3yxGTKsJZZpVjOjUbd0nWzjkjKxsp0O1us4vL5awwgvxpcdA4a0+j 30GGNS/qj1aqgcdM8QKIvmeKTetVCf124d+G6Qb+0pp+3HILLdwS+mUkzGTxwNDYY9Ku DyWlXsWPZdJY+KYMnr1iVSmwxrZKEIq+5auE3+culkS7yaK3Rl94gExp/KThy1iq4EiN uaMSp911fkfmEN/Eozr2Qje7dyNFtwgEIAH//j5tt4Qllk5bDKzPWFeem8SIoOejeQhh ItLdPw/PBPqZLZJ8kZRdUrmk589Rtsonij6NXAFquIdCFaVjNcMS2o3/g9PhEvJzy471 ZDxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9gFYBrbf8YicLDWxzYBg4XLOYGuO28YsBTMKDArBJGg=; b=TenKH3lb+lSenoyy0c/lvXFoqcamJbnwRRkHL969FkC3L+Q/vWkTfYHDTfegh+P9/G bRnQ/eSH+irZvm2rpAbIsfq2tOGf+C63wmBxZJ1UImYsp/TZpOaIWJm3dOZ/hihttlI8 zWWGtbZit1NGPdh0qosKcUFi6VWXwOlqM2+WgHOfWWsPHkfv+Fi3sXiHKuwMguPHx6jM IrGy3fp44HwKpu8l5JGeo5CoovlJUIMz95UwajCYe/jxFN41mBvvzWL7VzWeJ3EN2uQO tE5hOBN7KnViCYxGktgA+sMwxbfNJ8PIzCL+etp906N0Tp5oA1NHzkTxXmbHWcxFZCAA mVRw== X-Gm-Message-State: AKS2vOzIcaJptcU6F7UVqVezHytc/0qLxmWpf7g/SM831nS02SS7OBXT MDtjRzR9f4p7IEBxdeSDHBAO+QbzuoLi X-Received: by 10.107.18.19 with SMTP id a19mr1590373ioj.93.1498497247462; Mon, 26 Jun 2017 10:14:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Mon, 26 Jun 2017 10:13:46 -0700 (PDT) In-Reply-To: References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> From: Marius Scurtescu Date: Mon, 26 Jun 2017 10:13:46 -0700 Message-ID: To: Mike Jones Cc: Justin Richer , Phil Hunt , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a113ee86e2267890552e0143d" Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:14:15 -0000 --001a113ee86e2267890552e0143d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Limit use cases, in what ways? The format is a bit more complex, yes, but that is not limiting anything. By defining a simpler base SET and then requiring the most important profiles to make it more complex anyhow is not helping at all IMO. As Phil mentioned, I think consistency is more important. But again, if use cases are indeed limited then please clarify how. Marius On Mon, Jun 26, 2017 at 10:05 AM, Mike Jones wrote: > Justin, > > > > The rules you=E2=80=99re proposing may be fine for a SET profile for a pa= rticular > kind of application. I encourage you to join the RISC working group and > work on them there. But they would limit the use cases that SETs could b= e > used for, which would be unfortunate and unnecessary. > > > > An analogy with JWT is illustrative. JWT is intentionally > general-purpose, leaving it up to application profiles what claims to use > and what their semantics are. This enables JWTs to be used for ID Tokens > and also > for completely unrelated uses, such as SIP > and Caller ID > . There is no > expectation of interoperability between these different JWT applications. > Indeed =E2=80=93 both the syntax **and the semantics**, such has how to d= etermine > what keys are valid, are different. It=E2=80=99s this flexibility that m= akes JWTs > general-purpose. > > > > Likewise, SET as currently specified is similarly general-purpose. > Application profiles define what SET claims to use and their semantics. = *There > is no expectation of interoperability between different SET profiles, nor > should there be*, as their applications are different. Trying to make > SETs require choices appropriate to a particular profile will necessarily > make them a poor or impossible fit for others. This would be a very bad > thing. > > > > Ironically, =E2=80=9Clocking down=E2=80=9D SET to require choices motivat= ed by a > particular profile wouldn=E2=80=99t help that profile at all, as it would= work the > same whether SET was =E2=80=9Clocked down=E2=80=9D or not. But it would = unnecessarily > preclude use of SETs in other contexts that they are currently a great fi= t > for. > > > > -- Mike > > > > *From:* Marius Scurtescu [mailto:mscurtescu@google.com] > *Sent:* Monday, June 26, 2017 9:43 AM > *To:* Justin Richer > *Cc:* Mike Jones ; Phil Hunt < > phil.hunt@oracle.com>; Richard Backman, Annabelle ; > John Bradley ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>; Yaron Sheffer ; > ID Events Mailing List > > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Justin, in the case when an RP is issuing the SET to send it to an IdP, a > top level sub as you describe it may not be possible. Or maybe I > misunderstand. > > > > We agree on "iss" I think, in this case it points to the RP. A top level > "sub" though is problematic, The RP in many cases has the opaque "sub" as > issued by the IdP, but this value is globally unique only when combined > with the IdP "iss". > > > > Not sure why event.aud would be necessary? > > > Marius > > > > On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer wrote: > > Mike, this is not at all what I see for having the "most support". Instea= d > I'm seeing a lot of call for having "sub" defined clearly in the event > payload only. > > The "sub" of the main body is the subject as known by the issuer of the > SET itself. This might be the same subject that the subject is known by a= t > the target of the SET. There are many cases where this isn't true, and so > far one exception case where it is, sometimes. We should not be writing > this for the exception. > > But I think there's a pretty clear path forward. The "sub" in the body of > a SET, if it is included, is *ALWAYS* in the context of the "iss" of the > SET. Always, full stop, no exceptions. No global namespaces, no > restrictions on content, no formats -- it's an opaque (to the SET standar= d) > value in the domain of the issuer of the SET. > > Event payloads, defined in profiles, describe a subject of the event > itself. Importantly, this is the subject as known by the context in which > the event will be *received*, not in which it was *issued*. Sometimes tho= se > are the same, more often (as we're seeing) we can't guarantee that. We > should not depend on that and we should not treat the exceptional case as > the usual, no matter what syntax another group has come up with. > > So here's the thing. I think the "sub" of an event should be optional, an= d > ALWAYS in the context of the issuer, and profiles should not places furth= er > constraints on that. Events themselves should be self-contained. I regret > that we didn't make the registration object in RFC7591 more self-containe= d, > as that's caused implementation and extension issues. I think events shou= ld > always have an internal subject/issuer pair, in the context of where the > event is being consumed. We need to define what iss/sub mean (in a grand > sense) inside the event object in this document, so that different events > don't reinvent the same thing over and over. If a profile wants to leave > that out because they don't need an identifier for the payload, then they > can leave it out. If they want to leave it out because they want to assum= e > there will "always" be an iss/sub in the root of the SET, then I have a > problem with that. The issuer of the SET can, and probably does, have its > own identifier which can't be assumed to be universal. Proposing a global > subject namespace or format, as has been suggested elsewhere on this list= , > is ludicrous and will never fly as it goes against how JWT namespacing fo= r > people and objects has always worked. We should have a clear semantic dat= a > structure that can be extended and used by all of the use cases that we'v= e > adopted. Optimizing at this stage, especially based on one event, is goin= g > to just lead to things being broken and back-patched later on. But if one > spec wants to leave out the iss/sub inside the event? They can still do > that, but I think that's pretty daft. > > > > In summary: > > - iss: issuer of the event > - sub: subject of the event as known by the issuer of the event > - event.sub: subject of the event as known by the recipient of the > event > - event.iss: context for the subject of the event as known by the > recipient of the event > - event.aud: recipient of the event > > > > -- Justin > > > > On 6/21/2017 7:45 PM, Mike Jones wrote: > > The proposal that I believe has the most support is keeping things as the= y > are, leaving it up to profiles and applications to define which claims th= ey > use and how they use them. > > > > It would be fine for some profiles to use the language below. > > > > =E2=80=93 Mike > > *From: *Phil Hunt > *Sent: *Wednesday, June 21, 2017 6:39 PM > *To: *Richard Backman, Annabelle > *Cc: *Marius Scurtescu ; John Bradley > ; Henk Birkholz ; Jus= tin > Richer ; Yaron Sheffer ; Mike > Jones ; ID Events Mailing List > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > So I understand what is being proposed is: > > > > If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, and= the issuer of > the subject is identical to the issuer for the event, then =E2=80=9Csub= =E2=80=9D may be > used at the top level. Otherwise, the subject of an event (e.g. =E2=80=9C= sub=E2=80=9D) and > any other claims required to uniquely identify the subject MUST be > contained in the event payload. > > > > For example, an ip address of 1.2.3.4 might be represented in a > =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. =E2=80=9C= ipaddress=E2=80=9D:=E2=80=9D1.2.3.4" > > A SCIM resource URI of https://scim.example.com/users/ > ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload > as: =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45c= e9a242bd3859c82c4 > =E2=80=9D > > > > A Connect Logout event from an OP uses the top level sub claim and depend= s > on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND the subj= ect. This means > that no party may issue logout events on behalf of the OP. > > > > > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect & Standards > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > Fair point. If we do not intend to support multiple profiles within a > single SET, then I=E2=80=99m less concerned about leaving sub semantics u= p to the > profiles. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Marius Scurtescu > *Date: *Wednesday, June 21, 2017 at 2:58 PM > *To: *"Richard Backman, Annabelle" > *Cc: *"Phil Hunt (IDM)" , John Bradley < > ve7jtb@ve7jtb.com>, Henk Birkholz , > Justin Richer , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Example for multiple events within same profile: IdP account is disabled > (because of hijacking), this can lead to two events: > > 1. "account-disabled" > > 2. "sessions-revoked" > > > Marius > > > > On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > The spec says that the events claim SHOULD NOT be used to express multipl= e > logical events. If it=E2=80=99s also not used to express events from diff= erent > profiles that correspond to the same logical event (e.g. an OIDC > backchannel logout event alongside a hypothetical RISC logout event), the= n > I=E2=80=99m not sure what use case that leaves for multiple events in one= SET. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of "Phil Hunt > (IDM)" > *Date: *Wednesday, June 21, 2017 at 2:12 PM > *To: *John Bradley > *Cc: *"Richard Backman, Annabelle" , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de>, Justin Richer , Marius > Scurtescu , Yaron Sheffer , > Michael Jones , ID Events Mailing List < > id-event@ietf.org> > > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Separate or combined may be evolving. Mike wants to keep the current > backchannel logout very narrowly scoped. He suggested risc define its own > duplicate definitions and meanings. > > > > That leads me to believe we will have multi-type events in practice. > > > > Session cancellation can occur for many reasons. One of the > differentiators we had tried to make was an assumption that user initiate= d > events would be part of connect. Risk would cover variations that drive o= ff > of risk calculations like password reset. > > > > There are also signout events at rp's to let the OP know. These are not > commands but notification that a resource session is cancelled. IOW singl= e > sign out not expected. > > > Phil > > > On Jun 21, 2017, at 1:58 PM, John Bradley wrote: > > I thought we decided that we are only allowing set messages form the same > family that agree on top level claims. > > > > Otherwise there can be no top level claims and we are really defining a > alternative format to JWT in some ways. > > > > John B. > > > > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > > I agree with John that the JWT type confusion problem and the SET sub > problem can and should be discussed separately. The secevents WG is > probably not the right setting to discuss the former. > > > > My concern with the sub claim is that two profiles may dictate conflictin= g > semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B say= s it=E2=80=99s an > email address). If these profiles don=E2=80=99t provide an alternate way = to declare > subject of their events, then they cannot be present within the same toke= n. > This incompatibility trap seems like something that could be easily misse= d > by groups profiling SET. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *John Bradley > *Date: *Wednesday, June 21, 2017 at 1:39 PM > *To: *Yaron Sheffer > *Cc: *Justin Richer , Marius Scurtescu < > mscurtescu@google.com>, Annabelle Richard , Phil > Hunt , Michael Jones , > ID Events Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > In the envelope typ is a media/mime type. Registering application/idt+jw= t > if we register jwt as a structured name sufix. > > > > Using the cty is also possible. I need to think about what is better bu= t > we can agree on a convention. > > > > Not everything is going to be a set token like not every JWS is a JWT. > > > > If we are going to define processing rules to stop collisions and > confusion around JWT for different purposes, we should just start using t= he > typ parameter based on the existing spec. > > > > In general content sniffing if there is more than one option eventually > gets you into trouble. > > > > I am not convinced that forcing there to be no sub at the top level is a > good idea. > > > > It is not the way we should differentiate between SET and id_tokens. > > > > If sub is not allowed at the top level people will do non SET JWT for > things where the subject is scoped to the iss of the token. > > > > I think defining sub to be part of the event for cases where the sub is > scoped differently from the issuer of the token is fine, but should not b= e > required for all event types. > > > > I think we should solve the confusion issue separately from the sub issue= . > > > > Sorry I am at CIS so trying to catch up on lists. > > > > John B. > > > > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer wrote: > > > > So to summarize what I'm seeing on this thread: > > Everybody agrees with Marius's short-term solution, specific rules for > "sub" and "iss" that can be defined in the SET spec. > > Almost everybody agrees on a long-term "usage" claim ("type" is taken) > that should be defined elsewhere, e.g. in the JWT BCP. > > Did I miss anything? > > By the way, if we do add a "usage" claim, we need to also use it in the > SET document before it is published. > > Thanks, > > Yaron > > > > On 15/06/17 22:08, Justin Richer wrote: > > +1 to this as well. > > > > =E2=80=94 Justin > > > > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > > > > +1 to what Annabelle said. > > > > Also, Mike you are missing the other requirement, for RPs to send events > to an IdP. The iss+sub pair at the top level is broken in this case. > > > Marius > > > > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > +1 > > > > Phil > > > > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > Mike, > > > > Your explanation for why this is a non-problem is dependent upon side > effects of elements of OpenID Connect that were not designed to solve thi= s > issue. As a result, I see several issues with it: > > 1. The caller of the Token Endpoint is the only party that can be > certain that a nonce-less ID Token is really an ID Token. Any party that > the caller passes the ID Token off to has no way to verify its provenance= . > > 2. Any future ID Token distribution method needs to solve this > problem again. > > 3. No other profile of JWT can ever use the "nonce=E2=80=9D claim. > > 4. This is only a solution for ID Tokens. Every other JWT profile > that cares about disambiguation has to invent its own solution to the > problem. > > > > We know from experience that naming collisions and replay attacks are bot= h > things that happen. What=E2=80=99s being proposed is a simple, defensive = measure > against these risks. You brought up JWT libraries: a general solution > actually makes it easier to use common libraries for JWT parsing. A > =E2=80=9Cusage-aware=E2=80=9D JWT library could handle disambiguation for= any JWT profile, > whereas with the status quo each profile would require unique logic. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Mike Jones < > Michael.Jones@microsoft.com> > *Date: *Wednesday, June 14, 2017 at 1:16 PM > *To: *Marius Scurtescu > *Cc: *"Richard Backman, Annabelle" , ID Events > Mailing List , Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. I=E2= =80=99d characterize the proposals > in this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 makin= g things that can and > should be simple complex, without data showing there=E2=80=99s any need t= o do so. > > > > Mandatory solutions are being proposed in this thread to problems that > there=E2=80=99s no evidence that we actually even have. It=E2=80=99s alr= eady been > established that it=E2=80=99s impossible for a SET to be confused for an = ID Token =E2=80=93 > see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html > . > If people have data showing that this is possible with specific kinds of > Access Tokens or other real JWT deployments, please provide specifics, so > that we can use that data to inform appropriate engineering choices on ou= r > part. > > > > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use of = =E2=80=9Csub=E2=80=9D in the > normal way, or requiring a type claim, would make previously simple thing= s > unnecessarily complex. Yes, then the result is then different than a > normal JWT but a consequence of this is that custom parsing code would ha= ve > to be used, rather than a standard JWT parser. The more unwieldy we make > it to use SETs, the more likely developers are to just create their own > data structures. Keeping it simple is the key to adoption. Standards ar= e > only useful if they are actually used. > > > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Richard Backman, Annabelle > *Sent:* Tuesday, June 13, 2017 5:33 PM > *To:* Marius Scurtescu ; Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > Echoing Marius=E2=80=99s question: can you explain what you mean by =E2= =80=9Cintend=E2=80=9D? > > > > To your first question, I think a better analogy would be the X.509 Key > Usage extension: a multi-valued property that declares the intended purpo= se > of the JWT, and that a recipient may refer to when determining whether to > accept a JWT being presented to it in some context. > > > > -- > > Annabelle Richard Backman > > Identity Services > > > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Tuesday, June 13, 2017 at 11:05 AM > *To: *Henk Birkholz > *Cc: *ID Events Mailing List > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > > > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz < > henk.birkholz@sit.fraunhofer.de> wrote: > > And a 2nd question. > > What semantics would "usage" provide that that are not covered via > "intend", "audience", and "scope"? > > > > "aud" (audience) specifies the target client, but not the intended usage > (access token to authorize resource access or SET to communicate a securi= ty > event?) > > > > "scope" is not used by SET. > > > > I don't know what do you mean by "intend" (or intent)? > > > > > > > > Henk > > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > > Thanks for putting this together! > > I think the assumptions inherent in 3.9 are flawed: > > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutua= lly exclusive > set of valid claims and/or header parameters, and enforcing this requires= a > =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to ensure that J= WTs from some > future spec can=E2=80=99t be mistaken for JWTs from a current spec. > > =C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9C= different keys > for different kinds of JWTs=E2=80=9D rule. Whether mandated by the spec o= r not, > implementers will ignore this because managing one key is easier than > managing N different keys. > > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims. > > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header p= arameter. > > -- > > Annabelle Richard Backman > > Identity Services > > *From: *Id-event on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > *Cc: *Adam Dawes , "matake, nov" , ID > Events Mailing List , "Phil Hunt (IDM)" < > phil.hunt@oracle.com> > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and > distinct SET issuer > > Agreed. Note that there is still lots of discussion on what should be in > 3.9. > > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu > wrote: > > Thanks for the pointer Dick, very good timing :-) > > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". > > I still think that a "type" claim would bring a lot of clarity and > safety. > > > Marius > > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > wrote: > > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 > > > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > wrote: > > I was initially a fan of keeping SETS to be very similar to > id tokens but I now think this is a better plan. > > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > wrote: > > +1 especially for "type" > > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >: > > +1 > > Phil > > > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > > wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: the > SET issuer in some cases must be different from the > "sub" issuer. This is the case of an RP sending SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please note > "should" and not "must" > > > > This solution also allows different profiles that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius > > > _______________________________________________ > > Id-event mailing list > > > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_ > jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= =3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > |+1 650-214-2410 > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > Subscribe to the HARDTWARE > > mail list to > learn about projects I am working on! > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=3D > P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=3D > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > > > --001a113ee86e2267890552e0143d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Limit use cases, in what ways?

The form= at is a bit more complex, yes, but that is not limiting anything. By defini= ng a simpler base SET and then requiring the most important profiles to mak= e it more complex anyhow is not helping at all IMO. As Phil mentioned, I th= ink consistency is more important.

But again, if u= se cases are indeed limited then please clarify how.

Marius


On Mon,= Jun 26, 2017 at 10:05 AM, Mike Jones <Michael.= Jones@microsoft.com> wrote:

Justin,<= /span>

=C2=A0

The rules you=E2=80=99= re proposing may be fine for a SET profile for a particular kind of applica= tion.=C2=A0 I encourage you to join the RISC working group and work on them= there.=C2=A0 But they would limit the use cases that SETs could be used for, which would be unfortunate and unnecessary.=

=C2=A0

An analogy with JWT is= illustrative.=C2=A0 JWT is intentionally general-purpose, leaving it up to= application profiles what claims to use and what their semantics are.=C2= =A0 This enables JWTs to be used for ID Tokens and also for completely unre= lated uses, such as SIP and Caller ID.=C2=A0 There is no expectation of interoperability between th= ese different JWT applications.=C2=A0 Indeed =E2=80=93 both the syntax *= and the semantics*, such has how to determine what keys are valid, are = different.=C2=A0 It=E2=80=99s this flexibility that makes JWTs general-purpose.

=C2=A0

Likewise, SET as curre= ntly specified is similarly general-purpose.=C2=A0 Application profiles def= ine what SET claims to use and their semantics.=C2=A0 There is no expectation of interoperability between different SET profil= es, nor should there be, as their applications are different.=C2=A0 Try= ing to make SETs require choices appropriate to a particular profile will n= ecessarily make them a poor or impossible fit for others.=C2=A0 This would be a very bad thing.=

=C2=A0

Ironically, =E2=80=9Cl= ocking down=E2=80=9D SET to require choices motivated by a particular profi= le wouldn=E2=80=99t help that profile at all, as it would work the same whe= ther SET was =E2=80=9Clocked down=E2=80=9D or not.=C2=A0 But it would unnec= essarily preclude use of SETs in other contexts that they are currently a great fit= for.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mik= e

=C2=A0

From: Marius Scurtescu [mailto:mscurtescu@go= ogle.com]
Sent: Monday, June 26, 2017 9:43 AM
To: Justin Richer <jricher@mit.edu>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Phil = Hunt <phil.hunt@oracle.com>; Richard Backman, Annabelle <richan= na@amazon.com>; John Bradley <ve7jtb@ve7jtb.com>; Henk Birkho= lz <henk.birkholz@sit.fraunhofer.de>; Yaron Sheff= er <yaronf.ietf@gmail.com>; ID Events Mailing List <id-event@ietf.org>


Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

Justin, in the case when an RP is issuing the SET to= send it to an IdP, a top level sub as you describe it may not be possible.= Or maybe I misunderstand.

=C2=A0

We agree on "iss" I think, in this case it= points to the RP. A top level "sub" though is problematic, The R= P in many cases has the opaque "sub" as issued by the IdP, but th= is value is globally unique only when combined with the IdP "iss"= .

=C2=A0

Not sure why event.aud would be necessary?=


Marius

=C2=A0

On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank" class=3D"cremed">jriche= r@mit.edu> wrote:

Mike, this is not at all what I see for having the "most support&qu= ot;. Instead I'm seeing a lot of call for having "sub" define= d clearly in the event payload only.

The "sub" of the main body is the subject as known by the issu= er of the SET itself. This might be the same subject that the subject is kn= own by at the target of the SET. There are many cases where this isn't = true, and so far one exception case where it is, sometimes. We should not be writing this for the exception.<= /p>

But I think there's a pretty clear path forward. The "sub"= in the body of a SET, if it is included, is *ALWAYS* in the context of the= "iss" of the SET. Always, full stop, no exceptions. No global na= mespaces, no restrictions on content, no formats -- it's an opaque (to the SET standard) value in the domain of the issuer of the S= ET.

Event payloads, defined in profiles, describe a subject of the event its= elf. Importantly, this is the subject as known by the context in which the = event will be *received*, not in which it was *issued*. Sometimes those are= the same, more often (as we're seeing) we can't guarantee that. We should not depend on that and we s= hould not treat the exceptional case as the usual, no matter what syntax an= other group has come up with.

So here's the thing. I think the "sub" of an event should = be optional, and ALWAYS in the context of the issuer, and profiles should n= ot places further constraints on that. Events themselves should be self-con= tained. I regret that we didn't make the registration object in RFC7591 more self-contained, as that's caused implementation= and extension issues. I think events should always have an internal subjec= t/issuer pair, in the context of where the event is being consumed. We need= to define what iss/sub mean (in a grand sense) inside the event object in this document, so that different events = don't reinvent the same thing over and over. If a profile wants to leav= e that out because they don't need an identifier for the payload, then = they can leave it out. If they want to leave it out because they want to assume there will "always" be an iss= /sub in the root of the SET, then I have a problem with that. The issuer of= the SET can, and probably does, have its own identifier which can't be= assumed to be universal. Proposing a global subject namespace or format, as has been suggested elsewhere on this list, is ludi= crous and will never fly as it goes against how JWT namespacing for people = and objects has always worked. We should have a clear semantic data structu= re that can be extended and used by all of the use cases that we've adopted. Optimizing at this stage, = especially based on one event, is going to just lead to things being broken= and back-patched later on. But if one spec wants to leave out the iss/sub = inside the event? They can still do that, but I think that's pretty daft.

=C2=A0

In summary:

  • iss: issuer of the event
  • sub: subject of the event as known by the issuer of the event=
  • event.sub: subject of the event as known by the recipient of the event
  • event.iss: context for the subject of the event as known by the recipient o= f the event
  • event.aud: recipient of the event

=C2=A0

=C2=A0-- Justin

=C2=A0

On 6/21/2017 7:45 PM, Mike Jones wrote:

The proposal that I believe has the most support is = keeping things as they are, leaving it up to profiles and applications to d= efine which claims they use and how they use them.

=C2=A0

It would be fine for some profiles to use the langua= ge below.

=C2=A0

=E2=80=93 Mike

From: Phil Hunt
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle
Cc: Marius Scurtescu; Joh= n Bradley; Henk Birkholz; Justin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List
Subject: Re: [Id-event] solution for Id/Access Token confusion and d= istinct SET issuer

=C2=A0

So I understand what is being proposed is:=

=C2=A0

= If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, and t= he issuer of the subject is identical to the issuer for the event, then =E2= =80=9Csub=E2=80=9D may be used at the top level. Otherwise, the subject of = an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims required to unique= ly identify the subject MUST be contained in the event payload.

=C2=A0

For example, an ip address of 1.2.3.4 might be repre= sented in a =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload.= =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"

A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload as: =E2=80=9Csub=E2=80=9D:= "https://scim.example.com/use= rs/ac1faebbfd3c45ce9a242bd3859c82c4=E2=80=9D

=C2=A0

A Connect Logout event from an OP uses the top level= sub claim and depends on =E2=80=9Ciss=E2=80=9D being the same for the even= t issuer AND the subject. This means that no party may issue logout events = on behalf of the OP.

=C2=A0

=C2=A0

Phil

=C2=A0

Oracle Corporation, Iden= tity Cloud Services Architect & Standards

@independentid=

phil.hunt@oracle.com=

=C2=A0

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabe= lle <richanna@amazon.com> wrote:

=C2=A0

Fair point. If we do not = intend to support multiple profiles within a single SET, then I=E2=80=99m l= ess concerned about leaving sub semantics up to the profiles.=

=C2=A0<= /span>

--=C2=A0

Annabelle Richard Bac= kman

Identity Services<= /u>

=C2=A0<= /span>

=C2=A0<= /span>

From:=C2=A0Marius Scurtescu <mscurtescu@google.com>
Date:=C2=A0Wednesday, June 21, 2017 at 2:58 PM
To:=C2=A0"Richard Backman, Annabelle" <richa= nna@amazon.com>
Cc:=C2=A0"Phil Hunt (IDM)" <phil.hunt@oracl= e.com>, John Bradley <ve7jtb@ve7jtb.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>,= Justin Richer <jricher@mit.edu>, Yaron Sheffer <yaronf.ietf@gmail= .com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Ma= iling List <id-event@ietf.org>
Subject:=C2=A0Re: [Id-event] solution for Id/Access Toke= n confusion and distinct SET issuer

=C2=A0<= /span>

Example for multiple = events within same profile: IdP account is disabled (because of hijacking),= this can lead to two events:

1. "account-disa= bled"

2. "sessions-rev= oked"


Marius<= /span>

=C2=A0<= /span>

On Wed, Jun 21, 2017 = at 2:54 PM, Richard Backman, Annabelle <rich= anna@amazon.com> wrote:

The spec says that the ev= ents claim SHOULD NOT be used to express multiple logical events. If it=E2= =80=99s also not used to express events from different profiles that corres= pond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then= I=E2=80=99m not sure what use case that leaves for multiple events in one = SET.

=C2=A0

--=C2=A0<= /span>

Annabelle Richard Backm= an

Identity Services

=C2=A0

=C2=A0

From:=C2=A0Id-event <id-event-bounces@ietf.org> on behalf of "Phil Hunt (IDM)" <= phil.hunt@oracle.com>
Date:=C2=A0Wednesday, June 21, 2017 at 2:12 PM
To:=C2=A0John Bradley <ve7j= tb@ve7jtb.com>
Cc:=C2=A0"Richard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz &= lt;henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, = Marius Scurtescu <mscurtescu@google.com>, Yaron Sheffer <yaronf.ietf@gmail.com= >, Michael Jones <Michael.Jones@m= icrosoft.com>, ID Events Mailing List <id-event@ietf.org>


Subject:=C2=A0Re: [Id-event] solution for Id/Access Toke= n confusion and distinct SET issuer

=C2=A0

Separate or combined ma= y be evolving. Mike wants to keep the current backchannel logout very narro= wly scoped. He suggested risc define its own duplicate definitions and meanings.=C2=A0

=C2=A0

That leads me to believ= e we will have multi-type events in practice.

=C2=A0

Session cancellation ca= n occur for many reasons. One of the differentiators we had tried to make w= as an assumption that user initiated events would be part of connect. Risk would cover variations that drive off of risk cal= culations like password reset.=C2=A0

=C2=A0

There are also signout = events at rp's to let the OP know. These are not commands but notificat= ion that a resource session is cancelled. IOW single sign out not expected.=C2=A0


Phil

=
On Jun 21, 2017, at 1:58 PM, John Bradley <ve7= jtb@ve7jtb.com> wrote:

I thought we decided = that we are only allowing set messages form the same family that agree on t= op level claims.

=C2=A0<= /span>

Otherwise there can b= e no top level claims and we are really defining a alternative format to JW= T in some ways.

=C2=A0<= /span>

John B.=

=C2=A0<= /span>

On Jun 21, 2017, at 3:5= 4 PM, Richard Backman, Annabelle <richanna@a= mazon.com> wrote:

=C2=A0

I agree with John that th= e JWT type confusion problem and the SET sub problem can and should be disc= ussed separately. The secevents WG is probably not the right setting to dis= cuss the former.

=C2=A0<= /span>

My concern with the sub c= laim is that two profiles may dictate conflicting semantics (e.g. Profile A= says it=E2=80=99s a phone number, Profile B says it=E2=80=99s an email add= ress). If these profiles don=E2=80=99t provide an alternate way to declare subject of their events, then they cannot be present within= the same token. This incompatibility trap seems like something that could = be easily missed by groups profiling SET.

=C2=A0<= /span>

--=C2=A0<= /span>

Annabelle Richard Backm= an

Identity Services

=C2=A0<= /span>

=C2=A0<= /span>

From:=C2=A0John Bradley <ve7jtb@ve7= jtb.com>
Date:=C2=A0Wednesday, June 21, 2017= at 1:39 PM
To:=C2=A0Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=C2=A0Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle Richard <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com= >, Michael Jones <Michael.Jones@micros= oft.com>, ID Events Mailing List <id-event@ietf.org>, Henk Birkholz <henk.birkholz@si= t.fraunhofer.de>
Subject:=C2=A0Re: [Id-event] soluti= on for Id/Access Token confusion and distinct SET issuer

=C2=A0

In the envelope typ i= s a media/mime type.=C2=A0 Registering application/idt+jwt if we register j= wt as a structured name sufix. =C2=A0

=C2=A0

Using the cty is also p= ossible. =C2=A0 I need to think about what is better but we can agree on a = convention.

=C2=A0

Not everything is going= to be a set token like not every JWS is a JWT.

=C2=A0

If we are going to defi= ne processing rules to stop collisions and confusion around JWT for differe= nt purposes, we should just start using the typ parameter based on the existing spec.

=C2=A0

In general content snif= fing if there is more than one option eventually gets you into trouble.<= /u>

=C2=A0

I am not convinced that= forcing there to be no sub at the top level is a good idea. =C2=A0<= u>

=C2=A0

It is not the way we sh= ould differentiate between SET and id_tokens.

=C2=A0<= /span>

If sub is not allowed= at the top level people will do non SET JWT for things where the subject i= s scoped to the iss of the token.

=C2=A0<= /span>

I think defining sub = to be part of the event for cases where the sub is scoped differently from = the issuer of the token is fine, but should not be required for all event types.

=C2=A0<= /span>

I think we should sol= ve the confusion issue separately from the sub issue.<= /p>

=C2=A0<= /span>

Sorry I am at CIS so = trying to catch up on lists.

=C2=A0<= /span>

John B.=

=C2=A0<= /span>

On Jun 17, 2017, at 3:4= 5 PM, Yaron Sheffer <yaronf.ietf@gmail.com= > wrote:

=C2=A0

So to summarize what I&= #39;m seeing on this thread:

Everybody agrees with M= arius's short-term solution, specific rules for "sub" and &qu= ot;iss" that can be defined in the SET spec.

Almost everybody agrees= on a long-term "usage" claim ("type" is taken) that sh= ould be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?=

By the way, if we do ad= d a "usage" claim, we need to also use it in the SET document bef= ore it is published.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaro= n

=C2=A0

On 15/06/17 22:08, Just= in Richer wrote:

+1 to this as well.=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin<= u>

=C2=A0

On Jun 15, 2017, at 1:0= 9 PM, Marius Scurtescu <mscurtescu@google= .com> wrote:

=C2=A0

+1 to what Annabelle sa= id.=C2=A0

=C2=A0

Also, Mike you are miss= ing the other requirement, for RPs to send events to an IdP. The iss+sub pa= ir at the top level is broken in this case.


Marius

=C2=A0

On Wed, Jun 14, 2017 at= 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle= .com> wrote:

+1=

=C2=A0

Phil

=C2=A0

On Jun 14, 2017, at 5:2= 5 PM, Richard Backman, Annabelle <richanna@a= mazon.com> wrote:

Mike,

=C2=A0

Your explanation for why = this is a non-problem is dependent upon side effects of elements of OpenID = Connect that were not designed to solve this issue. As a result, I see seve= ral issues with it:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The caller of the Token Endpoint is the only party that can be c= ertain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token= off to has no way to verify its provenance.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Any future ID Token distribution method needs to solve this prob= lem again.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0No other profile of JWT can eve= r use the "nonce=E2=80=9D claim.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This is only a solution for ID = Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to = the problem.

=C2=A0

We know from experience t= hat naming collisions and replay attacks are both things that happen. What= =E2=80=99s being proposed is a simple, defensive measure against these risk= s. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A =E2=80= =9Cusage-aware=E2=80=9D JWT library could handle disambiguation for any JWT= profile, whereas with the status quo each profile would require unique log= ic.

=C2=A0

--=C2=A0<= /span>

Annabelle Richard Backm= an

Identity Services

=C2=A0

=C2=A0

From:=C2=A0Id-event <id-eve= nt-bounces@ietf.org> on behalf of Mike Jones <Michael.Jo= nes@microsoft.com>
Date:=C2=A0Wednesday, June 14, 2017= at 1:16 PM
To:=C2=A0Marius Scurtescu <mscurtescu@google.com>
Cc:=C2=A0"Richard Backman, Ann= abelle" <richanna@amazon.com= >, ID Events Mailing List <id-event@ietf.org>, Henk = Birkholz <henk.birkholz@sit.frau= nhofer.de>
Subject:=C2=A0Re: [Id-event] soluti= on for Id/Access Token confusion and distinct SET issuer

=C2=A0

You=E2=80=99ve heard of =E2=80=9Cpremature optimizatio= n=E2=80=9D.=C2=A0 I=E2=80=99d characterize the proposals in this thread as = =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making things that can an= d should be simple complex, without data showing there=E2=80=99s any need to do so.

=C2=A0

Mandatory solutions are being proposed in this thread = to problems that there=E2=80=99s no evidence that we actually even have.=C2= =A0 It=E2=80=99s already been established that it=E2=80=99s impossible for a SET to be confused for an ID Token =E2=80=93 see=C2=A0htt= ps://www.ietf.org/mail-archive/web/id-event/current/msg00428.html= .=C2=A0 If people have data showing that this is possible with specific kinds of A= ccess Tokens or other real JWT deployments, please provide specifics, so th= at we can use that data to inform appropriate engineering choices on our pa= rt.

=C2=A0

The proposed =E2=80=9Csolutions=E2=80=9D, such as proh= ibiting the use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a = type claim, would make previously simple things unnecessarily complex.=C2= =A0 Yes, then the result is then different than a normal JWT but a consequence= of this is that custom parsing code would have to be used, rather than a s= tandard JWT parser.=C2=A0 The more unwieldy we make it to use SETs, the mor= e likely developers are to just create their own data structures.=C2=A0 Keeping it simple is the key to adoption.= =C2=A0 Standards are only useful if they are actually used.=

=C2=A0

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

=C2=A0

From:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Richard Backman, Annab= elle
Sent:=C2=A0Tuesday, June 13, 2017 5= :33 PM
To:=C2=A0Marius Scurtes= cu <mscurtescu@google.com>; = Henk Birkholz <henk.birkholz@sit= .fraunhofer.de>
Cc:=C2=A0ID Events Mailing List <= ;id-event@ietf.org>
Subject:=C2=A0Re: [Id-event] soluti= on for Id/Access Token confusion and distinct SET issuer

=C2=A0

Echoing Marius=E2=80=99s = question: can you explain what you mean by =E2=80=9Cintend=E2=80=9D?

=C2=A0

To your first question, I= think a better analogy would be the X.509 Key Usage extension: a multi-val= ued property that declares the intended purpose of the JWT, and that a reci= pient may refer to when determining whether to accept a JWT being presented to it in some context.

=C2=A0

--=C2=A0<= /span>

Annabelle Richard Backm= an

Identity Services

=C2=A0

=C2=A0

From:=C2=A0Id-event <id-eve= nt-bounces@ietf.org> on behalf of Marius Scurtescu <mscurtescu= @google.com>
Date:=C2=A0Tuesday, June 13, 2017 a= t 11:05 AM
To:=C2=A0Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:=C2=A0ID Events Mailing L= ist <id-event@ietf.org>
Subject:=C2=A0Re: [Id-event] soluti= on for Id/Access Token confusion and distinct SET issuer=

=C2=A0

On Tue, Jun 13, 2017 at= 2:11 AM, Henk Birkholz <henk.bi= rkholz@sit.fraunhofer.de> wrote:

And a 2nd question.

What semantics would "usage" provide that that are not covered vi= a "intend", "audience", and "scope"?

=C2=A0

"aud" (audien= ce) specifies the target client, but not the intended usage (access token t= o authorize resource access or SET to communicate a security event?)

=C2=A0

"scope" is no= t used by SET.

=C2=A0

I don't know what d= o you mean by "intend" (or intent)?

=C2=A0

=C2=A0



Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:

Thanks= for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every type of JWT will have a mutuall= y exclusive set of valid claims and/or header parameters, and enforcing thi= s requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D approach to en= sure that JWTs from some future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers to adhere to the =E2=80=9Cdi= fferent keys for different kinds of JWTs=E2=80=9D rule. Whether mandated by= the spec or not, implementers will ignore this because managing one key is= easier than managing N different keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D claims.

+1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header par= ameter.

 --=C2=A0

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@iet= f.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <mscurtescu@google= .com>
*Cc: *Adam Dawes <adawes@google.com= >, "matake, nov" <nov@matake.jp>, ID Events Mailing List <id-event@ietf.org>, "= ;Phil Hunt (IDM)" <phil.hunt@oracle.= com>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distin= ct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.= 9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

=C2=A0 =C2=A0 Thanks for the pointer Dick, very good timing :-)

=C2=A0 =C2=A0 The issue is described by "2.7. Cross-JWT Confusion"= ; and the
=C2=A0 =C2=A0 mitigation is in "3.9. Use Mutually Exclusive Validation= Rules for
=C2=A0 =C2=A0 Different Kinds of JWTs", specifically "Use differe= nt sets of
=C2=A0 =C2=A0 required claims...", "Use different keys for differ= ent kinds of
=C2=A0 =C2=A0 JWTs." and "Use different issuers for different kin= ds of JWTs.".

=C2=A0 =C2=A0 I still think that a "type" claim would bring a lot= of clarity and
=C2=A0 =C2=A0 safety.


=C2=A0 =C2=A0 Marius

=C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
=C2=A0 =C2=A0 <mailto:dick.hardt@gmail.com<= /span>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron, Mike and I just published an BCP ID for = JWT
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0http://self-issued.info/?p=3D1690

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <<= a href=3D"mailto:adawes@google.com" target=3D"_blank" class=3D"cremed">adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@goo= gle.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I was initially a fan of keeping = SETS to be very similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id tokens but I now think this is= a better plan.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Jun 8, 2017 at 6:56 PM ma= take, nov <nov@matake.jp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:= nov@matake.jp>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1 especially for &= quot;type"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2017-06-09 10:32 GM= T+09:00 Phil Hunt (IDM)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:mscurtescu@google.com" target=3D"_blank" class=3D"cremed">= mscurtescu@google.com=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <mailto:mscurtescu@google.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were a couple of proposals on how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disti= nguish SETs from Id Tokens and Access Tokens in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = a way that naive implementations will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confu= se one for the other and open up security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vulne= rabilities.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There is also another important requirement: the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET i= ssuer in some cases must be different from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;sub" issuer. This is the case of an RP sending SETs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to an= IdP.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> With these requirements in mind I propose the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follo= wing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - both "sub" and "iss" to be defined at the eve= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" at event level and at top SET level can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be di= fferent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "iss" and "sub" at event level can be differe= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acros= s events in the same SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> - "sub" should NOT be present at the top SET
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level= (this solves the disambiguation), please note
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;should" and not "must"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> This solution also allows different profiles that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e event types to define additional claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relat= ed to sub (like email or phone_number) and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since= all these claims will be at the event level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there= will be no collisions or ambiguity.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Another proposal (which I supported) was to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defin= e a composite "aud" claim. This is not solving
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the r= equirement for a distinct=C2=A0 SET issuer. Also,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 havin= g the same claim name having different syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in di= fferent token types could lead to confusion.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> And yet another proposal was to introduce a new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 claim= for JWTs that defines a "type". This is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pract= ical in the short term, and it also is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solvi= ng the distinct issuer requirement, but I think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this = is something the JWT group should seriously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consi= der.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Thoughts?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Marius

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> Id-event mailing list

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>=C2=A0Id-= event@ietf.org=C2=A0<mailto:= Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://urlde= fense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR= 8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfx= qmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D<= /span>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-ev= ent mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.or= g=C2=A0<mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.i= etf.org/mailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing li= st
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:I= d-event@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/m= ailman/listinfo/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adam Dawes | Sr. Product Manager = |adawes@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:adawes@google.com> |+1 650-= 214-2410
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel= :(650)%20214-2410>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Id-event@ietf.org=C2=A0<mailto:Id-event@i= etf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/mailman/listinf= o/id-event

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subscribe to the HARDTWARE <http://hardtwa= re.com/> mail list to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 learn about projects I am working on!



--=C2=A0

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-= event


_______________________________________________
Id-event mailing list
Id-event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-= event

=C2=A0

=C2=A0

_______________________= ________________________
Id-event mailing list
Id-event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-= event

=C2=A0



___________________________________________=
____
Id-event mailing list
Id-event@ietf.org
https://www.ietf.=
org/mailman/listinfo/id-event

=C2=A0

_______________________= ________________________
Id-event mailing list
Id-event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-= event

=C2=A0<= /span>

=C2=A0<= /span>

_____________________= __________________________
Id-event mailing list
Id-event@ietf.org
= https://www.ietf.org/mailman/listinfo/id-= event

=C2=A0<= /span>

=C2=A0

=C2=A0

=C2=A0


--001a113ee86e2267890552e0143d-- From nobody Mon Jun 26 10:19:35 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E8126C83 for ; Mon, 26 Jun 2017 10:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ih3Wg0GUlIw for ; Mon, 26 Jun 2017 10:19:27 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0124.outbound.protection.outlook.com [104.47.40.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F061292FD for ; Mon, 26 Jun 2017 10:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tOeAPAG29ac6bfteu876M9oZiYOLm/P2SGwLL5CfHFE=; b=c97kqISOT8RaMDRDdRW/XPsis/KKuPOqnFlllQ1Z1t/P4BW2J/H+g/Il+xh4Slt7zqGI6I4NRnKZFCr/nk3H97eT6wVD0910/j+ZE6SIYF5Ys77HAXnqadsjl3pCasjJtBpp/5vZhtps2omHyJvBDSWxPe573vX36YjLsO5ig8s= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0183.namprd21.prod.outlook.com (10.173.193.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.1; Mon, 26 Jun 2017 17:19:24 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1220.008; Mon, 26 Jun 2017 17:19:24 +0000 From: Mike Jones To: Marius Scurtescu CC: Justin Richer , Phil Hunt , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , "Yaron Sheffer" , ID Events Mailing List Thread-Topic: [Id-event] solution for Id/Access Token confusion and distinct SET issuer Thread-Index: AQHS4L+9wo/ttGOlNk21y94S0EHb26Ibvu8AgAAGsYCAACMqAIAAEBEAgAXYe4CAAADegIAADAUAgACqWwCAAJUjgIAAbHaAgAFJ8nCAAEYlgIAAAiwAgAEWcwCAACElAIADP6wAgAZHxQCAAAQVgIAAAU6AgAAD8YCAAAu+gIAAARyAgAAK8YCAABEWAIAAAeGLgAWuUgCAAbcqAIAAANpggAAHvwCAAACo8A== Date: Mon, 26 Jun 2017 17:19:24 +0000 Message-ID: References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-26T10:19:22.4730922-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0183; 7:HKWC/R90cjNa+bh62L3s9KGuilmLTgBUwjXRdADOfYt+iRBbe25SJ6aQDyrHxpeoZm5AJVrPBf7ovDkGdLISgBfHD+0GdKsdFFbY4hFbqKhn5nWBNACmp+/d2CTpBhEZ4v1B0frLgN69dTy2i0xXv0zhwMYArPVrrj2w5vL9kcG85K6oypN+SsPRFnPOne7Ywxynojrp/P5XTPcpuMrbt/L88hX1ktehUSc/W9zMrOOF26XlckBFPUbdM1HSMvJL9fw5TgScvNuWOfQq7rjci5XGOxixZKXrFsq9IFRKzXRO2sU5g5Fp88zipd4AMwyfZracrFPRBNQgOGRE5fWeXht2hu48ull7syuyIb5lIwMTFGBwGM9wnQeHsXMCJJsqnqMJr9j1usMTobgu7OAXIpfNE/c9xxUTaBYuioJk6uKk1Yoenu+t8Pf8UqaxRBf/IUWwPHs3+1KKzM3nb4h2Pq0DCwh3lihZ+Eb0NkM/r29CXFQfWhI5jKIcjYqMpfq1t2oRZJgI+3u3hYc9Y28tBzn2IQb/mJaYAmyvxzsRBtzoGYQf8lsVeSbQ5NIH0eMhH9HBz8Jkj3eZsPMny8JdfIr6bI3n1yl+y+ONfUi6znO2vLF0EXeXHM16h6VWjDsDZe/01pydiDV3+rWdSgC+lqxrc4DUp9iz3NyF2uabpUsfP+xpHJA8G/MvLUW+pxVB69rrRd/9PswCXhs39sx4b42cfsnKkXuBbq/W2aIAjcGF/Mr01J2fdqysLa3rUIvPZgn6L9zhJlL7+VC1erk53Vdd2wEfpTD/NM6XzIpOb/nEeZs+ZckLppdYmFINrvzY x-ms-office365-filtering-correlation-id: a29ece0b-0c6e-4c1d-5abf-08d4bcb77e00 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:CY4PR21MB0183; x-ms-traffictypediagnostic: CY4PR21MB0183: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(133145235818549)(278428928389397)(26388249023172)(236129657087228)(192374486261705)(131327999870524)(90097320859284)(48057245064654); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0183; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0183; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39860400002)(39400400002)(39840400002)(39850400002)(209900001)(51444003)(51914003)(24454002)(377454003)(377424004)(6916009)(38730400002)(10090500001)(3660700001)(3280700002)(2950100002)(551544002)(5005710100001)(790700001)(6116002)(25786009)(102836003)(5660300001)(86612001)(2900100001)(55016002)(53946003)(99286003)(7906003)(8990500004)(54906002)(6506006)(7696004)(575784001)(6436002)(33656002)(561944003)(16200700003)(86362001)(53936002)(606005)(7066003)(6246003)(54896002)(9686003)(236005)(7520500002)(7736002)(81166006)(2906002)(50986999)(54356999)(6306002)(93886004)(74316002)(189998001)(10290500003)(4326008)(229853002)(72206003)(14454004)(53376002)(110136004)(122556002)(478600001)(53386004)(76176999)(77096006)(8676002)(966005)(8936002)(53546010)(19609705001)(39060400002)(579004)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0183; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB050497B3B24664BCC467D8E2F5DF0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 17:19:24.2539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0183 Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:19:34 -0000 --_000_CY4PR21MB050497B3B24664BCC467D8E2F5DF0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd291bGQgbGltaXQgdXNlIGNhc2VzIGluIHRoZSBzYW1lIHdheSB0aGF0LCBpZiB0aGUgYXV0 aG9ycyBvZiBKV1QgKHdobyB3ZXJlIGFsc28gdGhlIGF1dGhvcnMgb2YgdGhlIElEIFRva2VuKSwg 4oCcbG9ja2VkIGRvd27igJ0gSldUcyBzbyB0aGF0IHRoZXkgYWxsIHVzZWQgdGhlIHNhbWUgY2xh aW1zIGFuZCBzZW1hbnRpY3Mgb2YgSUQgVG9rZW5zLCB0aGVuIHRoZSBTSVA8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzgwNTU+IGFuZCBDYWxsZXIgSUQ8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtc3Rpci1wYXNzcG9ydC0xMT4gSldUIHByb2ZpbGVzIHdvdWxk IGhhdmUgbmV2ZXIgY29tZSBpbnRvIGV4aXN0ZW5jZS4gIEpXVHMgd291bGQgaGF2ZSBzdGlsbCB3 b3JrZWQgZm9yIElEIFRva2VucywgYnV0IHdlIHdvdWxkIGhhdmUgbmVlZGxlc3NseSBmb3JlY2xv c2VkIG90aGVyIHBvc3NpYmlsaXRpZXMgd2UgY291bGRu4oCZdCBldmVuIGltYWdpbmUsIHdoaWNo IGFyZSBqdXN0IGFzIGxlZ2l0aW1hdGUuDQoNCkZyb206IE1hcml1cyBTY3VydGVzY3UgW21haWx0 bzptc2N1cnRlc2N1QGdvb2dsZS5jb21dDQpTZW50OiBNb25kYXksIEp1bmUgMjYsIDIwMTcgMTA6 MTQgQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpDYzog SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PjsgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbT47IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29t PjsgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT47IEhlbmsgQmlya2hvbHogPGhlbmsu Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+OyBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBn bWFpbC5jb20+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVz aW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCkxpbWl0IHVzZSBjYXNlcywgaW4gd2hhdCB3 YXlzPw0KDQpUaGUgZm9ybWF0IGlzIGEgYml0IG1vcmUgY29tcGxleCwgeWVzLCBidXQgdGhhdCBp cyBub3QgbGltaXRpbmcgYW55dGhpbmcuIEJ5IGRlZmluaW5nIGEgc2ltcGxlciBiYXNlIFNFVCBh bmQgdGhlbiByZXF1aXJpbmcgdGhlIG1vc3QgaW1wb3J0YW50IHByb2ZpbGVzIHRvIG1ha2UgaXQg bW9yZSBjb21wbGV4IGFueWhvdyBpcyBub3QgaGVscGluZyBhdCBhbGwgSU1PLiBBcyBQaGlsIG1l bnRpb25lZCwgSSB0aGluayBjb25zaXN0ZW5jeSBpcyBtb3JlIGltcG9ydGFudC4NCg0KQnV0IGFn YWluLCBpZiB1c2UgY2FzZXMgYXJlIGluZGVlZCBsaW1pdGVkIHRoZW4gcGxlYXNlIGNsYXJpZnkg aG93Lg0KDQpNYXJpdXMNCg0KDQpPbiBNb24sIEp1biAyNiwgMjAxNyBhdCAxMDowNSBBTSwgTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkp1c3RpbiwNCg0KVGhlIHJ1bGVzIHlvdeKAmXJlIHBy b3Bvc2luZyBtYXkgYmUgZmluZSBmb3IgYSBTRVQgcHJvZmlsZSBmb3IgYSBwYXJ0aWN1bGFyIGtp bmQgb2YgYXBwbGljYXRpb24uICBJIGVuY291cmFnZSB5b3UgdG8gam9pbiB0aGUgUklTQyB3b3Jr aW5nIGdyb3VwIGFuZCB3b3JrIG9uIHRoZW0gdGhlcmUuICBCdXQgdGhleSB3b3VsZCBsaW1pdCB0 aGUgdXNlIGNhc2VzIHRoYXQgU0VUcyBjb3VsZCBiZSB1c2VkIGZvciwgd2hpY2ggd291bGQgYmUg dW5mb3J0dW5hdGUgYW5kIHVubmVjZXNzYXJ5Lg0KDQpBbiBhbmFsb2d5IHdpdGggSldUIGlzIGls bHVzdHJhdGl2ZS4gIEpXVCBpcyBpbnRlbnRpb25hbGx5IGdlbmVyYWwtcHVycG9zZSwgbGVhdmlu ZyBpdCB1cCB0byBhcHBsaWNhdGlvbiBwcm9maWxlcyB3aGF0IGNsYWltcyB0byB1c2UgYW5kIHdo YXQgdGhlaXIgc2VtYW50aWNzIGFyZS4gIFRoaXMgZW5hYmxlcyBKV1RzIHRvIGJlIHVzZWQgZm9y IElEIFRva2VuczxodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFf MC5odG1sI0lEVG9rZW4+IGFuZCBhbHNvIGZvciBjb21wbGV0ZWx5IHVucmVsYXRlZCB1c2VzLCBz dWNoIGFzIFNJUDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODA1NT4gYW5kIENhbGxl ciBJRDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0 LTExPi4gIFRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIG9mIGludGVyb3BlcmFiaWxpdHkgYmV0d2Vl biB0aGVzZSBkaWZmZXJlbnQgSldUIGFwcGxpY2F0aW9ucy4gIEluZGVlZCDigJMgYm90aCB0aGUg c3ludGF4ICphbmQgdGhlIHNlbWFudGljcyosIHN1Y2ggaGFzIGhvdyB0byBkZXRlcm1pbmUgd2hh dCBrZXlzIGFyZSB2YWxpZCwgYXJlIGRpZmZlcmVudC4gIEl04oCZcyB0aGlzIGZsZXhpYmlsaXR5 IHRoYXQgbWFrZXMgSldUcyBnZW5lcmFsLXB1cnBvc2UuDQoNCkxpa2V3aXNlLCBTRVQgYXMgY3Vy cmVudGx5IHNwZWNpZmllZCBpcyBzaW1pbGFybHkgZ2VuZXJhbC1wdXJwb3NlLiAgQXBwbGljYXRp b24gcHJvZmlsZXMgZGVmaW5lIHdoYXQgU0VUIGNsYWltcyB0byB1c2UgYW5kIHRoZWlyIHNlbWFu dGljcy4gIFRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIG9mIGludGVyb3BlcmFiaWxpdHkgYmV0d2Vl biBkaWZmZXJlbnQgU0VUIHByb2ZpbGVzLCBub3Igc2hvdWxkIHRoZXJlIGJlLCBhcyB0aGVpciBh cHBsaWNhdGlvbnMgYXJlIGRpZmZlcmVudC4gIFRyeWluZyB0byBtYWtlIFNFVHMgcmVxdWlyZSBj aG9pY2VzIGFwcHJvcHJpYXRlIHRvIGEgcGFydGljdWxhciBwcm9maWxlIHdpbGwgbmVjZXNzYXJp bHkgbWFrZSB0aGVtIGEgcG9vciBvciBpbXBvc3NpYmxlIGZpdCBmb3Igb3RoZXJzLiAgVGhpcyB3 b3VsZCBiZSBhIHZlcnkgYmFkIHRoaW5nLg0KDQpJcm9uaWNhbGx5LCDigJxsb2NraW5nIGRvd27i gJ0gU0VUIHRvIHJlcXVpcmUgY2hvaWNlcyBtb3RpdmF0ZWQgYnkgYSBwYXJ0aWN1bGFyIHByb2Zp bGUgd291bGRu4oCZdCBoZWxwIHRoYXQgcHJvZmlsZSBhdCBhbGwsIGFzIGl0IHdvdWxkIHdvcmsg dGhlIHNhbWUgd2hldGhlciBTRVQgd2FzIOKAnGxvY2tlZCBkb3du4oCdIG9yIG5vdC4gIEJ1dCBp dCB3b3VsZCB1bm5lY2Vzc2FyaWx5IHByZWNsdWRlIHVzZSBvZiBTRVRzIGluIG90aGVyIGNvbnRl eHRzIHRoYXQgdGhleSBhcmUgY3VycmVudGx5IGEgZ3JlYXQgZml0IGZvci4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogTWFyaXVzIFNjdXJ0ZXNjdSBbbWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xl LmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPl0NClNlbnQ6IE1vbmRheSwgSnVuZSAy NiwgMjAxNyA5OjQzIEFNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0 bzpqcmljaGVyQG1pdC5lZHU+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IFBoaWwgSHVudCA8 cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj47IFJpY2hh cmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5u YUBhbWF6b24uY29tPj47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZl N2p0YkB2ZTdqdGIuY29tPj47IEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVu aG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+PjsgWWFyb24g U2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5j b20+PjsgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlk LWV2ZW50QGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9y IElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KSnVz dGluLCBpbiB0aGUgY2FzZSB3aGVuIGFuIFJQIGlzIGlzc3VpbmcgdGhlIFNFVCB0byBzZW5kIGl0 IHRvIGFuIElkUCwgYSB0b3AgbGV2ZWwgc3ViIGFzIHlvdSBkZXNjcmliZSBpdCBtYXkgbm90IGJl IHBvc3NpYmxlLiBPciBtYXliZSBJIG1pc3VuZGVyc3RhbmQuDQoNCldlIGFncmVlIG9uICJpc3Mi IEkgdGhpbmssIGluIHRoaXMgY2FzZSBpdCBwb2ludHMgdG8gdGhlIFJQLiBBIHRvcCBsZXZlbCAi c3ViIiB0aG91Z2ggaXMgcHJvYmxlbWF0aWMsIFRoZSBSUCBpbiBtYW55IGNhc2VzIGhhcyB0aGUg b3BhcXVlICJzdWIiIGFzIGlzc3VlZCBieSB0aGUgSWRQLCBidXQgdGhpcyB2YWx1ZSBpcyBnbG9i YWxseSB1bmlxdWUgb25seSB3aGVuIGNvbWJpbmVkIHdpdGggdGhlIElkUCAiaXNzIi4NCg0KTm90 IHN1cmUgd2h5IGV2ZW50LmF1ZCB3b3VsZCBiZSBuZWNlc3Nhcnk/DQoNCk1hcml1cw0KDQpPbiBT dW4sIEp1biAyNSwgMjAxNyBhdCA3OjMxIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l ZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQpNaWtlLCB0aGlzIGlzIG5vdCBh dCBhbGwgd2hhdCBJIHNlZSBmb3IgaGF2aW5nIHRoZSAibW9zdCBzdXBwb3J0Ii4gSW5zdGVhZCBJ J20gc2VlaW5nIGEgbG90IG9mIGNhbGwgZm9yIGhhdmluZyAic3ViIiBkZWZpbmVkIGNsZWFybHkg aW4gdGhlIGV2ZW50IHBheWxvYWQgb25seS4NCg0KVGhlICJzdWIiIG9mIHRoZSBtYWluIGJvZHkg aXMgdGhlIHN1YmplY3QgYXMga25vd24gYnkgdGhlIGlzc3VlciBvZiB0aGUgU0VUIGl0c2VsZi4g VGhpcyBtaWdodCBiZSB0aGUgc2FtZSBzdWJqZWN0IHRoYXQgdGhlIHN1YmplY3QgaXMga25vd24g YnkgYXQgdGhlIHRhcmdldCBvZiB0aGUgU0VULiBUaGVyZSBhcmUgbWFueSBjYXNlcyB3aGVyZSB0 aGlzIGlzbid0IHRydWUsIGFuZCBzbyBmYXIgb25lIGV4Y2VwdGlvbiBjYXNlIHdoZXJlIGl0IGlz LCBzb21ldGltZXMuIFdlIHNob3VsZCBub3QgYmUgd3JpdGluZyB0aGlzIGZvciB0aGUgZXhjZXB0 aW9uLg0KDQpCdXQgSSB0aGluayB0aGVyZSdzIGEgcHJldHR5IGNsZWFyIHBhdGggZm9yd2FyZC4g VGhlICJzdWIiIGluIHRoZSBib2R5IG9mIGEgU0VULCBpZiBpdCBpcyBpbmNsdWRlZCwgaXMgKkFM V0FZUyogaW4gdGhlIGNvbnRleHQgb2YgdGhlICJpc3MiIG9mIHRoZSBTRVQuIEFsd2F5cywgZnVs bCBzdG9wLCBubyBleGNlcHRpb25zLiBObyBnbG9iYWwgbmFtZXNwYWNlcywgbm8gcmVzdHJpY3Rp b25zIG9uIGNvbnRlbnQsIG5vIGZvcm1hdHMgLS0gaXQncyBhbiBvcGFxdWUgKHRvIHRoZSBTRVQg c3RhbmRhcmQpIHZhbHVlIGluIHRoZSBkb21haW4gb2YgdGhlIGlzc3VlciBvZiB0aGUgU0VULg0K DQpFdmVudCBwYXlsb2FkcywgZGVmaW5lZCBpbiBwcm9maWxlcywgZGVzY3JpYmUgYSBzdWJqZWN0 IG9mIHRoZSBldmVudCBpdHNlbGYuIEltcG9ydGFudGx5LCB0aGlzIGlzIHRoZSBzdWJqZWN0IGFz IGtub3duIGJ5IHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSBldmVudCB3aWxsIGJlICpyZWNlaXZl ZCosIG5vdCBpbiB3aGljaCBpdCB3YXMgKmlzc3VlZCouIFNvbWV0aW1lcyB0aG9zZSBhcmUgdGhl IHNhbWUsIG1vcmUgb2Z0ZW4gKGFzIHdlJ3JlIHNlZWluZykgd2UgY2FuJ3QgZ3VhcmFudGVlIHRo YXQuIFdlIHNob3VsZCBub3QgZGVwZW5kIG9uIHRoYXQgYW5kIHdlIHNob3VsZCBub3QgdHJlYXQg dGhlIGV4Y2VwdGlvbmFsIGNhc2UgYXMgdGhlIHVzdWFsLCBubyBtYXR0ZXIgd2hhdCBzeW50YXgg YW5vdGhlciBncm91cCBoYXMgY29tZSB1cCB3aXRoLg0KDQpTbyBoZXJlJ3MgdGhlIHRoaW5nLiBJ IHRoaW5rIHRoZSAic3ViIiBvZiBhbiBldmVudCBzaG91bGQgYmUgb3B0aW9uYWwsIGFuZCBBTFdB WVMgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciwgYW5kIHByb2ZpbGVzIHNob3VsZCBub3Qg cGxhY2VzIGZ1cnRoZXIgY29uc3RyYWludHMgb24gdGhhdC4gRXZlbnRzIHRoZW1zZWx2ZXMgc2hv dWxkIGJlIHNlbGYtY29udGFpbmVkLiBJIHJlZ3JldCB0aGF0IHdlIGRpZG4ndCBtYWtlIHRoZSBy ZWdpc3RyYXRpb24gb2JqZWN0IGluIFJGQzc1OTEgbW9yZSBzZWxmLWNvbnRhaW5lZCwgYXMgdGhh dCdzIGNhdXNlZCBpbXBsZW1lbnRhdGlvbiBhbmQgZXh0ZW5zaW9uIGlzc3Vlcy4gSSB0aGluayBl dmVudHMgc2hvdWxkIGFsd2F5cyBoYXZlIGFuIGludGVybmFsIHN1YmplY3QvaXNzdWVyIHBhaXIs IGluIHRoZSBjb250ZXh0IG9mIHdoZXJlIHRoZSBldmVudCBpcyBiZWluZyBjb25zdW1lZC4gV2Ug bmVlZCB0byBkZWZpbmUgd2hhdCBpc3Mvc3ViIG1lYW4gKGluIGEgZ3JhbmQgc2Vuc2UpIGluc2lk ZSB0aGUgZXZlbnQgb2JqZWN0IGluIHRoaXMgZG9jdW1lbnQsIHNvIHRoYXQgZGlmZmVyZW50IGV2 ZW50cyBkb24ndCByZWludmVudCB0aGUgc2FtZSB0aGluZyBvdmVyIGFuZCBvdmVyLiBJZiBhIHBy b2ZpbGUgd2FudHMgdG8gbGVhdmUgdGhhdCBvdXQgYmVjYXVzZSB0aGV5IGRvbid0IG5lZWQgYW4g aWRlbnRpZmllciBmb3IgdGhlIHBheWxvYWQsIHRoZW4gdGhleSBjYW4gbGVhdmUgaXQgb3V0LiBJ ZiB0aGV5IHdhbnQgdG8gbGVhdmUgaXQgb3V0IGJlY2F1c2UgdGhleSB3YW50IHRvIGFzc3VtZSB0 aGVyZSB3aWxsICJhbHdheXMiIGJlIGFuIGlzcy9zdWIgaW4gdGhlIHJvb3Qgb2YgdGhlIFNFVCwg dGhlbiBJIGhhdmUgYSBwcm9ibGVtIHdpdGggdGhhdC4gVGhlIGlzc3VlciBvZiB0aGUgU0VUIGNh biwgYW5kIHByb2JhYmx5IGRvZXMsIGhhdmUgaXRzIG93biBpZGVudGlmaWVyIHdoaWNoIGNhbid0 IGJlIGFzc3VtZWQgdG8gYmUgdW5pdmVyc2FsLiBQcm9wb3NpbmcgYSBnbG9iYWwgc3ViamVjdCBu YW1lc3BhY2Ugb3IgZm9ybWF0LCBhcyBoYXMgYmVlbiBzdWdnZXN0ZWQgZWxzZXdoZXJlIG9uIHRo aXMgbGlzdCwgaXMgbHVkaWNyb3VzIGFuZCB3aWxsIG5ldmVyIGZseSBhcyBpdCBnb2VzIGFnYWlu c3QgaG93IEpXVCBuYW1lc3BhY2luZyBmb3IgcGVvcGxlIGFuZCBvYmplY3RzIGhhcyBhbHdheXMg d29ya2VkLiBXZSBzaG91bGQgaGF2ZSBhIGNsZWFyIHNlbWFudGljIGRhdGEgc3RydWN0dXJlIHRo YXQgY2FuIGJlIGV4dGVuZGVkIGFuZCB1c2VkIGJ5IGFsbCBvZiB0aGUgdXNlIGNhc2VzIHRoYXQg d2UndmUgYWRvcHRlZC4gT3B0aW1pemluZyBhdCB0aGlzIHN0YWdlLCBlc3BlY2lhbGx5IGJhc2Vk IG9uIG9uZSBldmVudCwgaXMgZ29pbmcgdG8ganVzdCBsZWFkIHRvIHRoaW5ncyBiZWluZyBicm9r ZW4gYW5kIGJhY2stcGF0Y2hlZCBsYXRlciBvbi4gQnV0IGlmIG9uZSBzcGVjIHdhbnRzIHRvIGxl YXZlIG91dCB0aGUgaXNzL3N1YiBpbnNpZGUgdGhlIGV2ZW50PyBUaGV5IGNhbiBzdGlsbCBkbyB0 aGF0LCBidXQgSSB0aGluayB0aGF0J3MgcHJldHR5IGRhZnQuDQoNCg0KDQpJbiBzdW1tYXJ5Og0K DQogICogICBpc3M6IGlzc3VlciBvZiB0aGUgZXZlbnQNCiAgKiAgIHN1Yjogc3ViamVjdCBvZiB0 aGUgZXZlbnQgYXMga25vd24gYnkgdGhlIGlzc3VlciBvZiB0aGUgZXZlbnQNCiAgKiAgIGV2ZW50 LnN1Yjogc3ViamVjdCBvZiB0aGUgZXZlbnQgYXMga25vd24gYnkgdGhlIHJlY2lwaWVudCBvZiB0 aGUgZXZlbnQNCiAgKiAgIGV2ZW50LmlzczogY29udGV4dCBmb3IgdGhlIHN1YmplY3Qgb2YgdGhl IGV2ZW50IGFzIGtub3duIGJ5IHRoZSByZWNpcGllbnQgb2YgdGhlIGV2ZW50DQogICogICBldmVu dC5hdWQ6IHJlY2lwaWVudCBvZiB0aGUgZXZlbnQNCg0KDQoNCiAtLSBKdXN0aW4NCg0KT24gNi8y MS8yMDE3IDc6NDUgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQpUaGUgcHJvcG9zYWwgdGhhdCBJIGJl bGlldmUgaGFzIHRoZSBtb3N0IHN1cHBvcnQgaXMga2VlcGluZyB0aGluZ3MgYXMgdGhleSBhcmUs IGxlYXZpbmcgaXQgdXAgdG8gcHJvZmlsZXMgYW5kIGFwcGxpY2F0aW9ucyB0byBkZWZpbmUgd2hp Y2ggY2xhaW1zIHRoZXkgdXNlIGFuZCBob3cgdGhleSB1c2UgdGhlbS4NCg0KSXQgd291bGQgYmUg ZmluZSBmb3Igc29tZSBwcm9maWxlcyB0byB1c2UgdGhlIGxhbmd1YWdlIGJlbG93Lg0KDQrigJMg TWlrZQ0KRnJvbTogUGhpbCBIdW50PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NClNlbnQ6 IFdlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyA2OjM5IFBNDQpUbzogUmljaGFyZCBCYWNrbWFuLCBB bm5hYmVsbGU8bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+DQpDYzogTWFyaXVzIFNjdXJ0ZXNj dTxtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tPjsgSm9obiBCcmFkbGV5PG1haWx0bzp2ZTdq dGJAdmU3anRiLmNvbT47IEhlbmsgQmlya2hvbHo8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZy YXVuaG9mZXIuZGU+OyBKdXN0aW4gUmljaGVyPG1haWx0bzpqcmljaGVyQG1pdC5lZHU+OyBZYXJv biBTaGVmZmVyPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+OyBNaWtlIEpvbmVzPG1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBJRCBFdmVudHMgTWFpbGluZyBMaXN0PG1h aWx0bzppZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9u IGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoN ClNvIEkgdW5kZXJzdGFuZCB3aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGlzOg0KDQpJZiB0aGUgZXZl bnQgdHlwZSB1c2VzIOKAnHN1YuKAnSB0byBpZGVudGlmeSBpdHMgc3ViamVjdCwgYW5kIHRoZSBp c3N1ZXIgb2YgdGhlIHN1YmplY3QgaXMgaWRlbnRpY2FsIHRvIHRoZSBpc3N1ZXIgZm9yIHRoZSBl dmVudCwgdGhlbiDigJxzdWLigJ0gbWF5IGJlIHVzZWQgYXQgdGhlIHRvcCBsZXZlbC4gT3RoZXJ3 aXNlLCB0aGUgc3ViamVjdCBvZiBhbiBldmVudCAoZS5nLiDigJxzdWLigJ0pIGFuZCBhbnkgb3Ro ZXIgY2xhaW1zIHJlcXVpcmVkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBzdWJqZWN0IE1VU1Qg YmUgY29udGFpbmVkIGluIHRoZSBldmVudCBwYXlsb2FkLg0KDQpGb3IgZXhhbXBsZSwgYW4gaXAg YWRkcmVzcyBvZiAxLjIuMy40IG1pZ2h0IGJlIHJlcHJlc2VudGVkIGluIGEg4oCcaXBhZGRyZXNz 4oCdIGNsYWltIGRlZmluZWQgaW4gdGhlIGV2ZW50IHBheWxvYWQuIOKAnGlwYWRkcmVzc+KAnTri gJ0xLjIuMy40Ig0KQSBTQ0lNIHJlc291cmNlIFVSSSBvZiBodHRwczovL3NjaW0uZXhhbXBsZS5j b20vdXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5YzgyYzQgbWlnaHQgYmUgaWRlbnRp ZmllZCBpbiB0aGUgZXZlbnQgcGF5bG9hZCBhczog4oCcc3Vi4oCdOiJodHRwczovL3NjaW0uZXhh bXBsZS5jb20vdXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5YzgyYzTigJ0NCg0KQSBD b25uZWN0IExvZ291dCBldmVudCBmcm9tIGFuIE9QIHVzZXMgdGhlIHRvcCBsZXZlbCBzdWIgY2xh aW0gYW5kIGRlcGVuZHMgb24g4oCcaXNz4oCdIGJlaW5nIHRoZSBzYW1lIGZvciB0aGUgZXZlbnQg aXNzdWVyIEFORCB0aGUgc3ViamVjdC4gVGhpcyBtZWFucyB0aGF0IG5vIHBhcnR5IG1heSBpc3N1 ZSBsb2dvdXQgZXZlbnRzIG9uIGJlaGFsZiBvZiB0aGUgT1AuDQoNCg0KUGhpbA0KDQpPcmFjbGUg Q29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdCAmIFN0YW5kYXJk cw0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVw ZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPg0KDQpPbiBKdW4gMjEsIDIwMTcsIGF0IDM6MzggUE0sIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29t Pj4gd3JvdGU6DQoNCkZhaXIgcG9pbnQuIElmIHdlIGRvIG5vdCBpbnRlbmQgdG8gc3VwcG9ydCBt dWx0aXBsZSBwcm9maWxlcyB3aXRoaW4gYSBzaW5nbGUgU0VULCB0aGVuIEnigJltIGxlc3MgY29u Y2VybmVkIGFib3V0IGxlYXZpbmcgc3ViIHNlbWFudGljcyB1cCB0byB0aGUgcHJvZmlsZXMuDQoN Ci0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZy b206IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyBhdCAyOjU4 IFBNDQpUbzogIlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIiA8cmljaGFubmFAYW1hem9uLmNv bTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+DQpDYzogIlBoaWwgSHVudCAoSURNKSIgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+LCBKb2huIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+LCBIZW5r IEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpoZW5rLmJp cmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVk dTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdt YWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4sIE1pY2hhZWwgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPj4sIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3Ig SWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpFeGFt cGxlIGZvciBtdWx0aXBsZSBldmVudHMgd2l0aGluIHNhbWUgcHJvZmlsZTogSWRQIGFjY291bnQg aXMgZGlzYWJsZWQgKGJlY2F1c2Ugb2YgaGlqYWNraW5nKSwgdGhpcyBjYW4gbGVhZCB0byB0d28g ZXZlbnRzOg0KMS4gImFjY291bnQtZGlzYWJsZWQiDQoyLiAic2Vzc2lvbnMtcmV2b2tlZCINCg0K TWFyaXVzDQoNCk9uIFdlZCwgSnVuIDIxLCAyMDE3IGF0IDI6NTQgUE0sIFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24u Y29tPj4gd3JvdGU6DQpUaGUgc3BlYyBzYXlzIHRoYXQgdGhlIGV2ZW50cyBjbGFpbSBTSE9VTEQg Tk9UIGJlIHVzZWQgdG8gZXhwcmVzcyBtdWx0aXBsZSBsb2dpY2FsIGV2ZW50cy4gSWYgaXTigJlz IGFsc28gbm90IHVzZWQgdG8gZXhwcmVzcyBldmVudHMgZnJvbSBkaWZmZXJlbnQgcHJvZmlsZXMg dGhhdCBjb3JyZXNwb25kIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQgKGUuZy4gYW4gT0lEQyBi YWNrY2hhbm5lbCBsb2dvdXQgZXZlbnQgYWxvbmdzaWRlIGEgaHlwb3RoZXRpY2FsIFJJU0MgbG9n b3V0IGV2ZW50KSwgdGhlbiBJ4oCZbSBub3Qgc3VyZSB3aGF0IHVzZSBjYXNlIHRoYXQgbGVhdmVz IGZvciBtdWx0aXBsZSBldmVudHMgaW4gb25lIFNFVC4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCklkZW50aXR5IFNlcnZpY2VzDQoNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgIlBoaWwgSHVudCAoSURNKSIgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpw aGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcgYXQg MjoxMiBQTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0 YkB2ZTdqdGIuY29tPj4NCkNjOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5u YUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4sIEhlbmsgQmlya2hvbHog PGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGU+PiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpq cmljaGVyQG1pdC5lZHU+PiwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29t PG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiwgWWFyb24gU2hlZmZlciA8eWFyb25mLmll dGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiwgTWljaGFlbCBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOmlkLWV2ZW50QGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRp b24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXIN Cg0KU2VwYXJhdGUgb3IgY29tYmluZWQgbWF5IGJlIGV2b2x2aW5nLiBNaWtlIHdhbnRzIHRvIGtl ZXAgdGhlIGN1cnJlbnQgYmFja2NoYW5uZWwgbG9nb3V0IHZlcnkgbmFycm93bHkgc2NvcGVkLiBI ZSBzdWdnZXN0ZWQgcmlzYyBkZWZpbmUgaXRzIG93biBkdXBsaWNhdGUgZGVmaW5pdGlvbnMgYW5k IG1lYW5pbmdzLg0KDQpUaGF0IGxlYWRzIG1lIHRvIGJlbGlldmUgd2Ugd2lsbCBoYXZlIG11bHRp LXR5cGUgZXZlbnRzIGluIHByYWN0aWNlLg0KDQpTZXNzaW9uIGNhbmNlbGxhdGlvbiBjYW4gb2Nj dXIgZm9yIG1hbnkgcmVhc29ucy4gT25lIG9mIHRoZSBkaWZmZXJlbnRpYXRvcnMgd2UgaGFkIHRy aWVkIHRvIG1ha2Ugd2FzIGFuIGFzc3VtcHRpb24gdGhhdCB1c2VyIGluaXRpYXRlZCBldmVudHMg d291bGQgYmUgcGFydCBvZiBjb25uZWN0LiBSaXNrIHdvdWxkIGNvdmVyIHZhcmlhdGlvbnMgdGhh dCBkcml2ZSBvZmYgb2YgcmlzayBjYWxjdWxhdGlvbnMgbGlrZSBwYXNzd29yZCByZXNldC4NCg0K VGhlcmUgYXJlIGFsc28gc2lnbm91dCBldmVudHMgYXQgcnAncyB0byBsZXQgdGhlIE9QIGtub3cu IFRoZXNlIGFyZSBub3QgY29tbWFuZHMgYnV0IG5vdGlmaWNhdGlvbiB0aGF0IGEgcmVzb3VyY2Ug c2Vzc2lvbiBpcyBjYW5jZWxsZWQuIElPVyBzaW5nbGUgc2lnbiBvdXQgbm90IGV4cGVjdGVkLg0K DQpQaGlsDQoNCk9uIEp1biAyMSwgMjAxNywgYXQgMTo1OCBQTSwgSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgdGhvdWdo dCB3ZSBkZWNpZGVkIHRoYXQgd2UgYXJlIG9ubHkgYWxsb3dpbmcgc2V0IG1lc3NhZ2VzIGZvcm0g dGhlIHNhbWUgZmFtaWx5IHRoYXQgYWdyZWUgb24gdG9wIGxldmVsIGNsYWltcy4NCg0KT3RoZXJ3 aXNlIHRoZXJlIGNhbiBiZSBubyB0b3AgbGV2ZWwgY2xhaW1zIGFuZCB3ZSBhcmUgcmVhbGx5IGRl ZmluaW5nIGEgYWx0ZXJuYXRpdmUgZm9ybWF0IHRvIEpXVCBpbiBzb21lIHdheXMuDQoNCkpvaG4g Qi4NCg0KT24gSnVuIDIxLCAyMDE3LCBhdCAzOjU0IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdy b3RlOg0KDQpJIGFncmVlIHdpdGggSm9obiB0aGF0IHRoZSBKV1QgdHlwZSBjb25mdXNpb24gcHJv YmxlbSBhbmQgdGhlIFNFVCBzdWIgcHJvYmxlbSBjYW4gYW5kIHNob3VsZCBiZSBkaXNjdXNzZWQg c2VwYXJhdGVseS4gVGhlIHNlY2V2ZW50cyBXRyBpcyBwcm9iYWJseSBub3QgdGhlIHJpZ2h0IHNl dHRpbmcgdG8gZGlzY3VzcyB0aGUgZm9ybWVyLg0KDQpNeSBjb25jZXJuIHdpdGggdGhlIHN1YiBj bGFpbSBpcyB0aGF0IHR3byBwcm9maWxlcyBtYXkgZGljdGF0ZSBjb25mbGljdGluZyBzZW1hbnRp Y3MgKGUuZy4gUHJvZmlsZSBBIHNheXMgaXTigJlzIGEgcGhvbmUgbnVtYmVyLCBQcm9maWxlIEIg c2F5cyBpdOKAmXMgYW4gZW1haWwgYWRkcmVzcykuIElmIHRoZXNlIHByb2ZpbGVzIGRvbuKAmXQg cHJvdmlkZSBhbiBhbHRlcm5hdGUgd2F5IHRvIGRlY2xhcmUgc3ViamVjdCBvZiB0aGVpciBldmVu dHMsIHRoZW4gdGhleSBjYW5ub3QgYmUgcHJlc2VudCB3aXRoaW4gdGhlIHNhbWUgdG9rZW4uIFRo aXMgaW5jb21wYXRpYmlsaXR5IHRyYXAgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBjb3VsZCBi ZSBlYXNpbHkgbWlzc2VkIGJ5IGdyb3VwcyBwcm9maWxpbmcgU0VULg0KDQotLQ0KQW5uYWJlbGxl IFJpY2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBKb2huIEJyYWRs ZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+DQpEYXRlOiBX ZWRuZXNkYXksIEp1bmUgMjEsIDIwMTcgYXQgMTozOSBQTQ0KVG86IFlhcm9uIFNoZWZmZXIgPHlh cm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4NCkNjOiBK dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+LCBN YXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VA Z29vZ2xlLmNvbT4+LCBBbm5hYmVsbGUgUmljaGFyZCA8cmljaGFubmFAYW1hem9uLmNvbTxtYWls dG86cmljaGFubmFAYW1hem9uLmNvbT4+LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+LCBNaWNoYWVsIEpvbmVzIDxNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+LCBJ RCBFdmVudHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmc+PiwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5k ZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpTdWJqZWN0OiBSZTog W0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlz dGluY3QgU0VUIGlzc3Vlcg0KDQpJbiB0aGUgZW52ZWxvcGUgdHlwIGlzIGEgbWVkaWEvbWltZSB0 eXBlLiAgUmVnaXN0ZXJpbmcgYXBwbGljYXRpb24vaWR0K2p3dCBpZiB3ZSByZWdpc3RlciBqd3Qg YXMgYSBzdHJ1Y3R1cmVkIG5hbWUgc3VmaXguDQoNClVzaW5nIHRoZSBjdHkgaXMgYWxzbyBwb3Nz aWJsZS4gICBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgd2hhdCBpcyBiZXR0ZXIgYnV0IHdlIGNhbiBh Z3JlZSBvbiBhIGNvbnZlbnRpb24uDQoNCk5vdCBldmVyeXRoaW5nIGlzIGdvaW5nIHRvIGJlIGEg c2V0IHRva2VuIGxpa2Ugbm90IGV2ZXJ5IEpXUyBpcyBhIEpXVC4NCg0KSWYgd2UgYXJlIGdvaW5n IHRvIGRlZmluZSBwcm9jZXNzaW5nIHJ1bGVzIHRvIHN0b3AgY29sbGlzaW9ucyBhbmQgY29uZnVz aW9uIGFyb3VuZCBKV1QgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcywgd2Ugc2hvdWxkIGp1c3Qgc3Rh cnQgdXNpbmcgdGhlIHR5cCBwYXJhbWV0ZXIgYmFzZWQgb24gdGhlIGV4aXN0aW5nIHNwZWMuDQoN CkluIGdlbmVyYWwgY29udGVudCBzbmlmZmluZyBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIG9w dGlvbiBldmVudHVhbGx5IGdldHMgeW91IGludG8gdHJvdWJsZS4NCg0KSSBhbSBub3QgY29udmlu Y2VkIHRoYXQgZm9yY2luZyB0aGVyZSB0byBiZSBubyBzdWIgYXQgdGhlIHRvcCBsZXZlbCBpcyBh IGdvb2QgaWRlYS4NCg0KSXQgaXMgbm90IHRoZSB3YXkgd2Ugc2hvdWxkIGRpZmZlcmVudGlhdGUg YmV0d2VlbiBTRVQgYW5kIGlkX3Rva2Vucy4NCg0KSWYgc3ViIGlzIG5vdCBhbGxvd2VkIGF0IHRo ZSB0b3AgbGV2ZWwgcGVvcGxlIHdpbGwgZG8gbm9uIFNFVCBKV1QgZm9yIHRoaW5ncyB3aGVyZSB0 aGUgc3ViamVjdCBpcyBzY29wZWQgdG8gdGhlIGlzcyBvZiB0aGUgdG9rZW4uDQoNCkkgdGhpbmsg ZGVmaW5pbmcgc3ViIHRvIGJlIHBhcnQgb2YgdGhlIGV2ZW50IGZvciBjYXNlcyB3aGVyZSB0aGUg c3ViIGlzIHNjb3BlZCBkaWZmZXJlbnRseSBmcm9tIHRoZSBpc3N1ZXIgb2YgdGhlIHRva2VuIGlz IGZpbmUsIGJ1dCBzaG91bGQgbm90IGJlIHJlcXVpcmVkIGZvciBhbGwgZXZlbnQgdHlwZXMuDQoN CkkgdGhpbmsgd2Ugc2hvdWxkIHNvbHZlIHRoZSBjb25mdXNpb24gaXNzdWUgc2VwYXJhdGVseSBm cm9tIHRoZSBzdWIgaXNzdWUuDQoNClNvcnJ5IEkgYW0gYXQgQ0lTIHNvIHRyeWluZyB0byBjYXRj aCB1cCBvbiBsaXN0cy4NCg0KSm9obiBCLg0KDQpPbiBKdW4gMTcsIDIwMTcsIGF0IDM6NDUgUE0s IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQoNClNvIHRvIHN1bW1hcml6ZSB3aGF0IEknbSBzZWVpbmcgb24g dGhpcyB0aHJlYWQ6DQpFdmVyeWJvZHkgYWdyZWVzIHdpdGggTWFyaXVzJ3Mgc2hvcnQtdGVybSBz b2x1dGlvbiwgc3BlY2lmaWMgcnVsZXMgZm9yICJzdWIiIGFuZCAiaXNzIiB0aGF0IGNhbiBiZSBk ZWZpbmVkIGluIHRoZSBTRVQgc3BlYy4NCkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEgbG9u Zy10ZXJtICJ1c2FnZSIgY2xhaW0gKCJ0eXBlIiBpcyB0YWtlbikgdGhhdCBzaG91bGQgYmUgZGVm aW5lZCBlbHNld2hlcmUsIGUuZy4gaW4gdGhlIEpXVCBCQ1AuDQpEaWQgSSBtaXNzIGFueXRoaW5n Pw0KQnkgdGhlIHdheSwgaWYgd2UgZG8gYWRkIGEgInVzYWdlIiBjbGFpbSwgd2UgbmVlZCB0byBh bHNvIHVzZSBpdCBpbiB0aGUgU0VUIGRvY3VtZW50IGJlZm9yZSBpdCBpcyBwdWJsaXNoZWQuDQpU aGFua3MsDQogICAgWWFyb24NCg0KT24gMTUvMDYvMTcgMjI6MDgsIEp1c3RpbiBSaWNoZXIgd3Jv dGU6DQorMSB0byB0aGlzIGFzIHdlbGwuDQoNCiDigJQgSnVzdGluDQoNCk9uIEp1biAxNSwgMjAx NywgYXQgMTowOSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1h aWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiB3cm90ZToNCg0KKzEgdG8gd2hhdCBBbm5hYmVs bGUgc2FpZC4NCg0KQWxzbywgTWlrZSB5b3UgYXJlIG1pc3NpbmcgdGhlIG90aGVyIHJlcXVpcmVt ZW50LCBmb3IgUlBzIHRvIHNlbmQgZXZlbnRzIHRvIGFuIElkUC4gVGhlIGlzcytzdWIgcGFpciBh dCB0aGUgdG9wIGxldmVsIGlzIGJyb2tlbiBpbiB0aGlzIGNhc2UuDQoNCk1hcml1cw0KDQpPbiBX ZWQsIEp1biAxNCwgMjAxNyBhdCA1OjMzIFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KKzENCg0KUGhp bA0KDQpPbiBKdW4gMTQsIDIwMTcsIGF0IDU6MjUgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3Jv dGU6DQpNaWtlLA0KDQpZb3VyIGV4cGxhbmF0aW9uIGZvciB3aHkgdGhpcyBpcyBhIG5vbi1wcm9i bGVtIGlzIGRlcGVuZGVudCB1cG9uIHNpZGUgZWZmZWN0cyBvZiBlbGVtZW50cyBvZiBPcGVuSUQg Q29ubmVjdCB0aGF0IHdlcmUgbm90IGRlc2lnbmVkIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEFzIGEg cmVzdWx0LCBJIHNlZSBzZXZlcmFsIGlzc3VlcyB3aXRoIGl0Og0KDQoxLiAgICAgICBUaGUgY2Fs bGVyIG9mIHRoZSBUb2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBj ZXJ0YWluIHRoYXQgYSBub25jZS1sZXNzIElEIFRva2VuIGlzIHJlYWxseSBhbiBJRCBUb2tlbi4g QW55IHBhcnR5IHRoYXQgdGhlIGNhbGxlciBwYXNzZXMgdGhlIElEIFRva2VuIG9mZiB0byBoYXMg bm8gd2F5IHRvIHZlcmlmeSBpdHMgcHJvdmVuYW5jZS4NCg0KMi4gICAgICAgQW55IGZ1dHVyZSBJ RCBUb2tlbiBkaXN0cmlidXRpb24gbWV0aG9kIG5lZWRzIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBh Z2Fpbi4NCg0KMy4gICAgICBObyBvdGhlciBwcm9maWxlIG9mIEpXVCBjYW4gZXZlciB1c2UgdGhl ICJub25jZeKAnSBjbGFpbS4NCg0KNC4gICAgICBUaGlzIGlzIG9ubHkgYSBzb2x1dGlvbiBmb3Ig SUQgVG9rZW5zLiBFdmVyeSBvdGhlciBKV1QgcHJvZmlsZSB0aGF0IGNhcmVzIGFib3V0IGRpc2Ft YmlndWF0aW9uIGhhcyB0byBpbnZlbnQgaXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4N Cg0KV2Uga25vdyBmcm9tIGV4cGVyaWVuY2UgdGhhdCBuYW1pbmcgY29sbGlzaW9ucyBhbmQgcmVw bGF5IGF0dGFja3MgYXJlIGJvdGggdGhpbmdzIHRoYXQgaGFwcGVuLiBXaGF04oCZcyBiZWluZyBw cm9wb3NlZCBpcyBhIHNpbXBsZSwgZGVmZW5zaXZlIG1lYXN1cmUgYWdhaW5zdCB0aGVzZSByaXNr cy4gWW91IGJyb3VnaHQgdXAgSldUIGxpYnJhcmllczogYSBnZW5lcmFsIHNvbHV0aW9uIGFjdHVh bGx5IG1ha2VzIGl0IGVhc2llciB0byB1c2UgY29tbW9uIGxpYnJhcmllcyBmb3IgSldUIHBhcnNp bmcuIEEg4oCcdXNhZ2UtYXdhcmXigJ0gSldUIGxpYnJhcnkgY291bGQgaGFuZGxlIGRpc2FtYmln dWF0aW9uIGZvciBhbnkgSldUIHByb2ZpbGUsIHdoZXJlYXMgd2l0aCB0aGUgc3RhdHVzIHF1byBl YWNoIHByb2ZpbGUgd291bGQgcmVxdWlyZSB1bmlxdWUgbG9naWMuDQoNCi0tDQpBbm5hYmVsbGUg UmljaGFyZCBCYWNrbWFuDQpJZGVudGl0eSBTZXJ2aWNlcw0KDQoNCkZyb206IElkLWV2ZW50IDxp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3Jn Pj4gb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSnVu ZSAxNCwgMjAxNyBhdCAxOjE2IFBNDQpUbzogTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBn b29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pg0KQ2M6ICJSaWNoYXJkIEJh Y2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFt YXpvbi5jb20+PiwgSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFp bHRvOmlkLWV2ZW50QGlldGYub3JnPj4sIEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0 LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+Pg0K U3ViamVjdDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25m dXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KWW914oCZdmUgaGVhcmQgb2Yg4oCccHJl bWF0dXJlIG9wdGltaXphdGlvbuKAnS4gIEnigJlkIGNoYXJhY3Rlcml6ZSB0aGUgcHJvcG9zYWxz IGluIHRoaXMgdGhyZWFkIGFzIOKAnHByZW1hdHVyZSBwZXNzaW1hdGlvbuKAnSDigJMgbWFraW5n IHRoaW5ncyB0aGF0IGNhbiBhbmQgc2hvdWxkIGJlIHNpbXBsZSBjb21wbGV4LCB3aXRob3V0IGRh dGEgc2hvd2luZyB0aGVyZeKAmXMgYW55IG5lZWQgdG8gZG8gc28uDQoNCk1hbmRhdG9yeSBzb2x1 dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGluIHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQg dGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQgd2UgYWN0dWFsbHkgZXZlbiBoYXZlLiAgSXTigJlz IGFscmVhZHkgYmVlbiBlc3RhYmxpc2hlZCB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZvciBhIFNF VCB0byBiZSBjb25mdXNlZCBmb3IgYW4gSUQgVG9rZW4g4oCTIHNlZSBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lkLWV2ZW50L2N1cnJlbnQvbXNnMDA0MjguaHRtbDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQtMkRldmVudF9jdXJyZW50X21zZzAwNDI4Lmh0bWwm ZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9 SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBL SHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmcz1lS0xUUVBtWXJWM1RoZkRibjkwU0Nz NTVVUk9UUGluX2xnYzZSZHI1WG93JmU9Pi4gIElmIHBlb3BsZSBoYXZlIGRhdGEgc2hvd2luZyB0 aGF0IHRoaXMgaXMgcG9zc2libGUgd2l0aCBzcGVjaWZpYyBraW5kcyBvZiBBY2Nlc3MgVG9rZW5z IG9yIG90aGVyIHJlYWwgSldUIGRlcGxveW1lbnRzLCBwbGVhc2UgcHJvdmlkZSBzcGVjaWZpY3Ms IHNvIHRoYXQgd2UgY2FuIHVzZSB0aGF0IGRhdGEgdG8gaW5mb3JtIGFwcHJvcHJpYXRlIGVuZ2lu ZWVyaW5nIGNob2ljZXMgb24gb3VyIHBhcnQuDQoNClRoZSBwcm9wb3NlZCDigJxzb2x1dGlvbnPi gJ0sIHN1Y2ggYXMgcHJvaGliaXRpbmcgdGhlIHVzZSBvZiDigJxzdWLigJ0gaW4gdGhlIG5vcm1h bCB3YXksIG9yIHJlcXVpcmluZyBhIHR5cGUgY2xhaW0sIHdvdWxkIG1ha2UgcHJldmlvdXNseSBz aW1wbGUgdGhpbmdzIHVubmVjZXNzYXJpbHkgY29tcGxleC4gIFllcywgdGhlbiB0aGUgcmVzdWx0 IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4gYSBub3JtYWwgSldUIGJ1dCBhIGNvbnNlcXVlbmNlIG9m IHRoaXMgaXMgdGhhdCBjdXN0b20gcGFyc2luZyBjb2RlIHdvdWxkIGhhdmUgdG8gYmUgdXNlZCwg cmF0aGVyIHRoYW4gYSBzdGFuZGFyZCBKV1QgcGFyc2VyLiAgVGhlIG1vcmUgdW53aWVsZHkgd2Ug bWFrZSBpdCB0byB1c2UgU0VUcywgdGhlIG1vcmUgbGlrZWx5IGRldmVsb3BlcnMgYXJlIHRvIGp1 c3QgY3JlYXRlIHRoZWlyIG93biBkYXRhIHN0cnVjdHVyZXMuICBLZWVwaW5nIGl0IHNpbXBsZSBp cyB0aGUga2V5IHRvIGFkb3B0aW9uLiAgU3RhbmRhcmRzIGFyZSBvbmx5IHVzZWZ1bCBpZiB0aGV5 IGFyZSBhY3R1YWxseSB1c2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE0NClRvOiBNYXJpdXMgU2N1cnRl c2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+ OyBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPG1haWx0bzpo ZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBM aXN0IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tlbiBjb25mdXNpb24g YW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXINCg0KRWNob2luZyBNYXJpdXPigJlzIHF1ZXN0aW9uOiBj YW4geW91IGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBieSDigJxpbnRlbmTigJ0/DQoNClRvIHlvdXIg Zmlyc3QgcXVlc3Rpb24sIEkgdGhpbmsgYSBiZXR0ZXIgYW5hbG9neSB3b3VsZCBiZSB0aGUgWC41 MDkgS2V5IFVzYWdlIGV4dGVuc2lvbjogYSBtdWx0aS12YWx1ZWQgcHJvcGVydHkgdGhhdCBkZWNs YXJlcyB0aGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSldULCBhbmQgdGhhdCBhIHJlY2lwaWVu dCBtYXkgcmVmZXIgdG8gd2hlbiBkZXRlcm1pbmluZyB3aGV0aGVyIHRvIGFjY2VwdCBhIEpXVCBi ZWluZyBwcmVzZW50ZWQgdG8gaXQgaW4gc29tZSBjb250ZXh0Lg0KDQotLQ0KQW5uYWJlbGxlIFJp Y2hhcmQgQmFja21hbg0KSWRlbnRpdHkgU2VydmljZXMNCg0KDQpGcm9tOiBJZC1ldmVudCA8aWQt ZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFp bHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3 IGF0IDExOjA1IEFNDQpUbzogSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZTxtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4+DQpDYzogSUQg RXZlbnRzIE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3Mg VG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyDQoNCk9uIFR1ZSwgSnVuIDEz LCAyMDE3IGF0IDI6MTEgQU0sIEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVu aG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+PiB3cm90ZToN CkFuZCBhIDJuZCBxdWVzdGlvbi4NCg0KV2hhdCBzZW1hbnRpY3Mgd291bGQgInVzYWdlIiBwcm92 aWRlIHRoYXQgdGhhdCBhcmUgbm90IGNvdmVyZWQgdmlhICJpbnRlbmQiLCAiYXVkaWVuY2UiLCBh bmQgInNjb3BlIj8NCg0KImF1ZCIgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdldCBjbGll bnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0aG9yaXpl IHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1cml0eSBldmVudD8p DQoNCiJzY29wZSIgaXMgbm90IHVzZWQgYnkgU0VULg0KDQpJIGRvbid0IGtub3cgd2hhdCBkbyB5 b3UgbWVhbiBieSAiaW50ZW5kIiAob3IgaW50ZW50KT8NCg0KDQoNCg0KSGVuaw0KDQpPbiAwNi8x My8yMDE3IDAxOjAxIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSB3cm90ZToNClRoYW5r cyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyIQ0KDQpJIHRoaW5rIHRoZSBhc3N1bXB0aW9ucyBp bmhlcmVudCBpbiAzLjkgYXJlIGZsYXdlZDoNCg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0 IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwgaGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2Yg dmFsaWQgY2xhaW1zIGFuZC9vciBoZWFkZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0aGlz IHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBhbiB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9hY2gg dG8gZW5zdXJlIHRoYXQgSldUcyBmcm9tIHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0 YWtlbiBmb3IgSldUcyBmcm9tIGEgY3VycmVudCBzcGVjLg0KDQrCt0l0IGlzIHVucmVhbGlzdGlj IHRvIGV4cGVjdCBpbXBsZW1lbnRlcnMgdG8gYWRoZXJlIHRvIHRoZSDigJxkaWZmZXJlbnQga2V5 cyBmb3IgZGlmZmVyZW50IGtpbmRzIG9mIEpXVHPigJ0gcnVsZS4gV2hldGhlciBtYW5kYXRlZCBi eSB0aGUgc3BlYyBvciBub3QsIGltcGxlbWVudGVycyB3aWxsIGlnbm9yZSB0aGlzIGJlY2F1c2Ug bWFuYWdpbmcgb25lIGtleSBpcyBlYXNpZXIgdGhhbiBtYW5hZ2luZyBOIGRpZmZlcmVudCBrZXlz Lg0KDQrCt0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBjbGFpbXMuDQoNCisxIGZv ciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRlci4NCg0K LS0NCg0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KDQpJZGVudGl0eSBTZXJ2aWNlcw0KKkZy b206ICpJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdt YWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KKkRhdGU6ICpNb25kYXksIEp1 bmUgMTIsIDIwMTcgYXQgMzoxOCBQTQ0KKlRvOiAqTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNj dUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+Pg0KKkNjOiAqQWRhbSBE YXdlcyA8YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4sICJtYXRh a2UsIG5vdiIgPG5vdkBtYXRha2UuanA8bWFpbHRvOm5vdkBtYXRha2UuanA+PiwgSUQgRXZlbnRz IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50QGlldGYub3Jn Pj4sICJQaGlsIEh1bnQgKElETSkiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+Pg0KKlN1YmplY3Q6ICpSZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3Ig SWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcg0KDQpBZ3Jl ZWQuIE5vdGUgdGhhdCB0aGVyZSBpcyBzdGlsbCBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hhdCBz aG91bGQgYmUgaW4gMy45Lg0KDQpPbiBNb24sIEp1biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJp dXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29v Z2xlLmNvbT48bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbTxtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tPj4+IHdyb3RlOg0KDQogICAgVGhhbmtzIGZvciB0aGUgcG9pbnRlciBEaWNrLCB2 ZXJ5IGdvb2QgdGltaW5nIDotKQ0KDQogICAgVGhlIGlzc3VlIGlzIGRlc2NyaWJlZCBieSAiMi43 LiBDcm9zcy1KV1QgQ29uZnVzaW9uIiBhbmQgdGhlDQogICAgbWl0aWdhdGlvbiBpcyBpbiAiMy45 LiBVc2UgTXV0dWFsbHkgRXhjbHVzaXZlIFZhbGlkYXRpb24gUnVsZXMgZm9yDQogICAgRGlmZmVy ZW50IEtpbmRzIG9mIEpXVHMiLCBzcGVjaWZpY2FsbHkgIlVzZSBkaWZmZXJlbnQgc2V0cyBvZg0K ICAgIHJlcXVpcmVkIGNsYWltcy4uLiIsICJVc2UgZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVu dCBraW5kcyBvZg0KICAgIEpXVHMuIiBhbmQgIlVzZSBkaWZmZXJlbnQgaXNzdWVycyBmb3IgZGlm ZmVyZW50IGtpbmRzIG9mIEpXVHMuIi4NCg0KICAgIEkgc3RpbGwgdGhpbmsgdGhhdCBhICJ0eXBl IiBjbGFpbSB3b3VsZCBicmluZyBhIGxvdCBvZiBjbGFyaXR5IGFuZA0KICAgIHNhZmV0eS4NCg0K DQogICAgTWFyaXVzDQoNCiAgICBPbiBUaHUsIEp1biA4LCAyMDE3IGF0IDk6NTkgUE0sIERpY2sg SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4N CiAgICA8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbT4+PiB3cm90ZToNCg0KICAgICAgICBZYXJvbiwgTWlrZSBhbmQgSSBqdXN0IHB1Ymxpc2hl ZCBhbiBCQ1AgSUQgZm9yIEpXVA0KICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0x NjkwPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19z ZWxmLTJEaXNzdWVkLmluZm9fLTNGcC0zRDE2OTAmZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9h aTExNWMmcz1hN1h2WjVqVGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmU9Pg0K DQogICAgICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgOTowMiBQTSBBZGFtIERhd2VzIDxhZGF3 ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20+DQogICAgICAgIDxtYWlsdG86 YWRhd2VzQGdvb2dsZS5jb208bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPj4+IHdyb3RlOg0KDQog ICAgICAgICAgICBJIHdhcyBpbml0aWFsbHkgYSBmYW4gb2Yga2VlcGluZyBTRVRTIHRvIGJlIHZl cnkgc2ltaWxhciB0bw0KICAgICAgICAgICAgaWQgdG9rZW5zIGJ1dCBJIG5vdyB0aGluayB0aGlz IGlzIGEgYmV0dGVyIHBsYW4uDQoNCiAgICAgICAgICAgIE9uIFRodSwgSnVuIDgsIDIwMTcgYXQg Njo1NiBQTSBtYXRha2UsIG5vdiA8bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4N CiAgICAgICAgICAgIDxtYWlsdG86bm92QG1hdGFrZS5qcDxtYWlsdG86bm92QG1hdGFrZS5qcD4+ PiB3cm90ZToNCg0KICAgICAgICAgICAgICAgICsxIGVzcGVjaWFsbHkgZm9yICJ0eXBlIg0KDQog ICAgICAgICAgICAgICAgMjAxNy0wNi0wOSAxMDozMiBHTVQrMDk6MDAgUGhpbCBIdW50IChJRE0p DQogICAgICAgICAgICAgICAgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT48bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4+PjoNCg0KICAgICAgICAgICAgICAgICAgICArMQ0KDQogICAgICAgICAgICAg ICAgICAgIFBoaWwNCg0KDQogICAgICAgICAgICAgICAgICAgICA+IE9uIEp1biA4LCAyMDE3LCBh dCA2OjI4IFBNLCBNYXJpdXMgU2N1cnRlc2N1DQogICAgICAgICAgICAgICAgICAgIDxtc2N1cnRl c2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCiAgICAgICAgICAg ICAgICAgICAgPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VA Z29vZ2xlLmNvbT4+PiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAg ICAgICAgICAgID4gVGhlcmUgd2VyZSBhIGNvdXBsZSBvZiBwcm9wb3NhbHMgb24gaG93IHRvDQog ICAgICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBJZCBUb2tlbnMgYW5kIEFj Y2VzcyBUb2tlbnMgaW4NCiAgICAgICAgICAgICAgICAgICAgc3VjaCBhIHdheSB0aGF0IG5haXZl IGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdA0KICAgICAgICAgICAgICAgICAgICBjb25mdXNlIG9u ZSBmb3IgdGhlIG90aGVyIGFuZCBvcGVuIHVwIHNlY3VyaXR5DQogICAgICAgICAgICAgICAgICAg IHZ1bG5lcmFiaWxpdGllcy4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAg ICAgICAgID4gVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhl DQogICAgICAgICAgICAgICAgICAgIFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRp ZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAic3ViIiBpc3N1ZXIuIFRoaXMg aXMgdGhlIGNhc2Ugb2YgYW4gUlAgc2VuZGluZyBTRVRzDQogICAgICAgICAgICAgICAgICAgIHRv IGFuIElkUC4NCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4g V2l0aCB0aGVzZSByZXF1aXJlbWVudHMgaW4gbWluZCBJIHByb3Bvc2UgdGhlDQogICAgICAgICAg ICAgICAgICAgIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgID4gLSBib3RoICJzdWIi IGFuZCAiaXNzIiB0byBiZSBkZWZpbmVkIGF0IHRoZSBldmVudA0KICAgICAgICAgICAgICAgICAg ICBsZXZlbA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJpc3MiIGF0IGV2ZW50IGxldmVsIGFu ZCBhdCB0b3AgU0VUIGxldmVsIGNhbg0KICAgICAgICAgICAgICAgICAgICBiZSBkaWZmZXJlbnQN CiAgICAgICAgICAgICAgICAgICAgID4gLSAiaXNzIiBhbmQgInN1YiIgYXQgZXZlbnQgbGV2ZWwg Y2FuIGJlIGRpZmZlcmVudA0KICAgICAgICAgICAgICAgICAgICBhY3Jvc3MgZXZlbnRzIGluIHRo ZSBzYW1lIFNFVA0KICAgICAgICAgICAgICAgICAgICAgPiAtICJzdWIiIHNob3VsZCBOT1QgYmUg cHJlc2VudCBhdCB0aGUgdG9wIFNFVA0KICAgICAgICAgICAgICAgICAgICBsZXZlbCAodGhpcyBz b2x2ZXMgdGhlIGRpc2FtYmlndWF0aW9uKSwgcGxlYXNlIG5vdGUNCiAgICAgICAgICAgICAgICAg ICAgInNob3VsZCIgYW5kIG5vdCAibXVzdCINCiAgICAgICAgICAgICAgICAgICAgID4NCiAgICAg ICAgICAgICAgICAgICAgID4gVGhpcyBzb2x1dGlvbiBhbHNvIGFsbG93cyBkaWZmZXJlbnQgcHJv ZmlsZXMgdGhhdA0KICAgICAgICAgICAgICAgICAgICBkZWZpbmUgZXZlbnQgdHlwZXMgdG8gZGVm aW5lIGFkZGl0aW9uYWwgY2xhaW1zDQogICAgICAgICAgICAgICAgICAgIHJlbGF0ZWQgdG8gc3Vi IChsaWtlIGVtYWlsIG9yIHBob25lX251bWJlcikgYW5kDQogICAgICAgICAgICAgICAgICAgIHNp bmNlIGFsbCB0aGVzZSBjbGFpbXMgd2lsbCBiZSBhdCB0aGUgZXZlbnQgbGV2ZWwNCiAgICAgICAg ICAgICAgICAgICAgdGhlcmUgd2lsbCBiZSBubyBjb2xsaXNpb25zIG9yIGFtYmlndWl0eS4NCiAg ICAgICAgICAgICAgICAgICAgID4NCiAgICAgICAgICAgICAgICAgICAgID4gQW5vdGhlciBwcm9w b3NhbCAod2hpY2ggSSBzdXBwb3J0ZWQpIHdhcyB0bw0KICAgICAgICAgICAgICAgICAgICBkZWZp bmUgYSBjb21wb3NpdGUgImF1ZCIgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmcNCiAgICAgICAg ICAgICAgICAgICAgdGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0ICBTRVQgaXNzdWVyLiBB bHNvLA0KICAgICAgICAgICAgICAgICAgICBoYXZpbmcgdGhlIHNhbWUgY2xhaW0gbmFtZSBoYXZp bmcgZGlmZmVyZW50IHN5bnRheA0KICAgICAgICAgICAgICAgICAgICBpbiBkaWZmZXJlbnQgdG9r ZW4gdHlwZXMgY291bGQgbGVhZCB0byBjb25mdXNpb24uDQogICAgICAgICAgICAgICAgICAgICA+ DQogICAgICAgICAgICAgICAgICAgICA+IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8g aW50cm9kdWNlIGEgbmV3DQogICAgICAgICAgICAgICAgICAgIGNsYWltIGZvciBKV1RzIHRoYXQg ZGVmaW5lcyBhICJ0eXBlIi4gVGhpcyBpcyBub3QNCiAgICAgICAgICAgICAgICAgICAgcHJhY3Rp Y2FsIGluIHRoZSBzaG9ydCB0ZXJtLCBhbmQgaXQgYWxzbyBpcyBub3QNCiAgICAgICAgICAgICAg ICAgICAgc29sdmluZyB0aGUgZGlzdGluY3QgaXNzdWVyIHJlcXVpcmVtZW50LCBidXQgSSB0aGlu aw0KICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHNvbWV0aGluZyB0aGUgSldUIGdyb3VwIHNo b3VsZCBzZXJpb3VzbHkNCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIuDQogICAgICAgICAg ICAgICAgICAgICA+DQogICAgICAgICAgICAgICAgICAgICA+IFRob3VnaHRzPw0KICAgICAgICAg ICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICAgPiBNYXJpdXMNCiAgICAgICAgICAg ICAgICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICAgICAgICAgICAgICAgICAgID4gSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAg ICAgICAgICAgICAgICA+IElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0K ICAgICAgICAgICAgICAgICAgICAgPg0KICAgICAgICAgICAgICAgICAgICBodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBR Y3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xO S2U0Q19sTElHayZtPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcm cz01eFFxdkJpWFo2SWo5TkdEd1ZxWG9WcG44OFlLT0NkMG14UFFGSkxoeFdJJmU9DQoNCiAgICAg ICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgICAgICAgICAgICAgICAgSWQtZXZlbnQgbWFpbGluZyBsaXN0DQogICAgICAg ICAgICAgICAgICAgIElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4g PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+Pg0KICAg ICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhD c0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3 VG1HTVNXV3MmZT0+DQoNCiAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcg bGlzdA0KICAgICAgICAgICAgICAgIElkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4gPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmc+Pg0KICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FR JmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdq NzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXln N29NVTdUbUdNU1dXcyZlPT4NCg0KICAgICAgICAgICAgLS0NCiAgICAgICAgICAgIEFkYW0gRGF3 ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHxhZGF3ZXNAZ29vZ2xlLmNvbTxtYWlsdG86YWRhd2Vz QGdvb2dsZS5jb20+DQogICAgICAgICAgICA8bWFpbHRvOmFkYXdlc0Bnb29nbGUuY29tPG1haWx0 bzphZGF3ZXNAZ29vZ2xlLmNvbT4+IHwrMSA2NTAtMjE0LTI0MTA8dGVsOiUyQjElMjA2NTAtMjE0 LTI0MTA+DQogICAgICAgICAgICA8dGVsOig2NTApJTIwMjE0LTI0MTA8dGVsOiUyODY1MCUyOSUy MDIxNC0yNDEwPj4NCg0KICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgIElkLWV2ZW50IG1haWxpbmcgbGlzdA0KICAg ICAgICAgICAgSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPiA8bWFp bHRvOklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4+DQogICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBF aXZ6ald3bE5LZTRDX2xMSUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pS b2FpMTE1YyZzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+ DQoNCiAgICAgICAgLS0NCiAgICAgICAgU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkUgPGh0dHA6 Ly9oYXJkdHdhcmUuY29tLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZtPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTEx NWMmcz1pNzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmU9Pj4gbWFp bCBsaXN0IHRvDQogICAgICAgIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEN Cg0KDQoNCi0tDQoNClN1YnNjcmliZSB0byB0aGUgSEFSRFRXQVJFIDxodHRwOi8vaGFyZHR3YXJl LmNvbS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X2hhcmR0d2FyZS5jb21fJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZ VHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9aTc1VXc4 YWVoWXZscElaTkw3TnhxR3hoaDFUT3JRT1VYMlhNWUJlclY4MCZlPT4+IG1haWwgbGlzdCB0byBs ZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0 DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1 WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJm09VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZzPVA3bVp1 R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5ZzdvTVU3VG1HTVNXV3MmZT0+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxp c3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJnM9UDdt WnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPT4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcg bGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENzRGZ0LTAwWV8zelJv YWkxMTVjJnM9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZlPQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZl bnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBF aXZ6ald3bE5LZTRDX2xMSUdrJm09bC1PODJOTEktYjhRRGwyUTlUa3BWb2JRejNoXzRUeUJHQXE1 cGZac09jdyZzPTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0ODJDNzI5LVBFWUpoTHU1U1EmZT0+ DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCg0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk LWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdhUSZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09bC1PODJOTEktYjhRRGwyUTlUa3BWb2JR ejNoXzRUeUJHQXE1cGZac09jdyZzPTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0ODJDNzI5LVBF WUpoTHU1U1EmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNR2FRJmM9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3Vn Q0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1sLU84Mk5MSS1iOFFEbDJROVRrcFZv YlF6M2hfNFR5QkdBcTVwZlpzT2N3JnM9MExXUmxHVElxaVRzRGhtSHVSSUI1LVJSZnQ4MkM3Mjkt UEVZSmhMdTVTUSZlPT4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUdh USZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlS ckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09bC1PODJOTEktYjhRRGwyUTlU a3BWb2JRejNoXzRUeUJHQXE1cGZac09jdyZzPTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0ODJD NzI5LVBFWUpoTHU1U1EmZT0+DQoNCg0KDQoNCg0K --_000_CY4PR21MB050497B3B24664BCC467D8E2F5DF0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4ubTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV84NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcy OTQzNjg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4ubTg0MDE3MTY1MjgxMzEx Mjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV84NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2 OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNl O30NCnAubTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1 NjkzODUxNTk5ODhtOTA5NDA4OTIzOTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgsIGxpLm04NDAx NzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4 bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoLCBkaXYubTg0MDE3MTY1MjgxMzEx Mjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhtOTA5NDA4OTIz OTY2ODU3MDMxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV84NDAxNzE2NTI4 MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkwOTQw ODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5nYy1jcy1saW5rDQoJe21zby1zdHlsZS1uYW1lOmdjLWNzLWxp bms7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MjE0Njk2ODEwNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzU4MTgyNDYyO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JdCB3b3VsZCBsaW1pdCB1c2UgY2FzZXMgaW4g dGhlIHNhbWUgd2F5IHRoYXQsIGlmIHRoZSBhdXRob3JzIG9mIEpXVCAod2hvIHdlcmUgYWxzbyB0 aGUgYXV0aG9ycyBvZiB0aGUgSUQgVG9rZW4pLCDigJxsb2NrZWQgZG93buKAnSBKV1RzIHNvIHRo YXQgdGhleSBhbGwgdXNlZCB0aGUgc2FtZSBjbGFpbXMgYW5kIHNlbWFudGljcyBvZiBJRCBUb2tl bnMsIHRoZW4gdGhlPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDU1IiB0YXJnZXQ9Il9ibGFuayI+U0lQ PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c3Rpci1wYXNzcG9ydC0xMSIgdGFyZ2V0PSJfYmxhbmsiPg0KQ2FsbGVyIElEPC9hPiBKV1QgcHJv ZmlsZXMgd291bGQgaGF2ZSBuZXZlciBjb21lIGludG8gZXhpc3RlbmNlLiZuYnNwOyBKV1RzIHdv dWxkIGhhdmUgc3RpbGwgd29ya2VkIGZvciBJRCBUb2tlbnMsIGJ1dCB3ZSB3b3VsZCBoYXZlIG5l ZWRsZXNzbHkgZm9yZWNsb3NlZCBvdGhlciBwb3NzaWJpbGl0aWVzIHdlIGNvdWxkbuKAmXQgZXZl biBpbWFnaW5lLCB3aGljaCBhcmUganVzdCBhcyBsZWdpdGltYXRlLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNYXJpdXMgU2N1cnRlc2N1 IFttYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgSnVuZSAyNiwgMjAxNyAxMDoxNCBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVzdGluIFJp Y2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0OzsgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3Jh Y2xlLmNvbSZndDs7IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDtyaWNoYW5uYUBhbWF6 b24uY29tJmd0OzsgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs7IEhlbmsg Qmlya2hvbHogJmx0O2hlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUmZ3Q7OyBZYXJvbiBT aGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBJRCBFdmVudHMNCiBNYWlsaW5n IExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlz dGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGltaXQgdXNl IGNhc2VzLCBpbiB3aGF0IHdheXM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgZm9ybWF0IGlzIGEgYml0IG1vcmUgY29tcGxleCwgeWVzLCBidXQgdGhh dCBpcyBub3QgbGltaXRpbmcgYW55dGhpbmcuIEJ5IGRlZmluaW5nIGEgc2ltcGxlciBiYXNlIFNF VCBhbmQgdGhlbiByZXF1aXJpbmcgdGhlIG1vc3QgaW1wb3J0YW50IHByb2ZpbGVzIHRvIG1ha2Ug aXQgbW9yZSBjb21wbGV4IGFueWhvdyBpcyBub3QgaGVscGluZyBhdCBhbGwgSU1PLiBBcyBQaGls IG1lbnRpb25lZCwgSSB0aGluaw0KIGNvbnNpc3RlbmN5IGlzIG1vcmUgaW1wb3J0YW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgYWdh aW4sIGlmIHVzZSBjYXNlcyBhcmUgaW5kZWVkIGxpbWl0ZWQgdGhlbiBwbGVhc2UgY2xhcmlmeSBo b3cuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFy PSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1hcml1czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBKdW4gMjYsIDIwMTcgYXQgMTA6MDUgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhy ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPkp1c3Rpbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5UaGUgcnVsZXMgeW914oCZcmUgcHJvcG9zaW5nIG1heSBiZSBmaW5lIGZv ciBhIFNFVCBwcm9maWxlIGZvciBhIHBhcnRpY3VsYXIga2luZCBvZiBhcHBsaWNhdGlvbi4mbmJz cDsgSSBlbmNvdXJhZ2UgeW91IHRvIGpvaW4gdGhlIFJJU0Mgd29ya2luZyBncm91cCBhbmQgd29y aw0KIG9uIHRoZW0gdGhlcmUuJm5ic3A7IEJ1dCB0aGV5IHdvdWxkIGxpbWl0IHRoZSB1c2UgY2Fz ZXMgdGhhdCBTRVRzIGNvdWxkIGJlIHVzZWQgZm9yLCB3aGljaCB3b3VsZCBiZSB1bmZvcnR1bmF0 ZSBhbmQgdW5uZWNlc3NhcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+QW4gYW5hbG9neSB3aXRoIEpXVCBpcyBpbGx1c3RyYXRpdmUuJm5ic3A7IEpXVCBpcyBpbnRl bnRpb25hbGx5IGdlbmVyYWwtcHVycG9zZSwgbGVhdmluZyBpdCB1cCB0byBhcHBsaWNhdGlvbiBw cm9maWxlcyB3aGF0IGNsYWltcyB0byB1c2UgYW5kIHdoYXQgdGhlaXIgc2VtYW50aWNzDQogYXJl LiZuYnNwOyBUaGlzIGVuYWJsZXMgSldUcyB0byBiZSB1c2VkIGZvciA8YSBocmVmPSJodHRwOi8v b3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sI0lEVG9rZW4iIHRh cmdldD0iX2JsYW5rIj4NCklEIFRva2VuczwvYT4gYW5kIGFsc28gZm9yIGNvbXBsZXRlbHkgdW5y ZWxhdGVkIHVzZXMsIHN1Y2ggYXMgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzgwNTUiIHRhcmdldD0iX2JsYW5rIj4NClNJUDwvYT4gYW5kIDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQtMTEiIHRhcmdldD0i X2JsYW5rIj4NCkNhbGxlciBJRDwvYT4uJm5ic3A7IFRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIG9m IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGVzZSBkaWZmZXJlbnQgSldUIGFwcGxpY2F0aW9u cy4mbmJzcDsgSW5kZWVkIOKAkyBib3RoIHRoZSBzeW50YXggKjxiPmFuZCB0aGUgc2VtYW50aWNz PC9iPiosIHN1Y2ggaGFzIGhvdyB0byBkZXRlcm1pbmUgd2hhdCBrZXlzIGFyZSB2YWxpZCwgYXJl IGRpZmZlcmVudC4mbmJzcDsgSXTigJlzIHRoaXMgZmxleGliaWxpdHkgdGhhdCBtYWtlcyBKV1Rz DQogZ2VuZXJhbC1wdXJwb3NlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPkxpa2V3aXNlLCBTRVQgYXMgY3VycmVudGx5IHNwZWNpZmllZCBpcyBzaW1pbGFybHkgZ2Vu ZXJhbC1wdXJwb3NlLiZuYnNwOyBBcHBsaWNhdGlvbiBwcm9maWxlcyBkZWZpbmUgd2hhdCBTRVQg Y2xhaW1zIHRvIHVzZSBhbmQgdGhlaXIgc2VtYW50aWNzLiZuYnNwOw0KPGI+VGhlcmUgaXMgbm8g ZXhwZWN0YXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBTRVQgcHJv ZmlsZXMsIG5vciBzaG91bGQgdGhlcmUgYmU8L2I+LCBhcyB0aGVpciBhcHBsaWNhdGlvbnMgYXJl IGRpZmZlcmVudC4mbmJzcDsgVHJ5aW5nIHRvIG1ha2UgU0VUcyByZXF1aXJlIGNob2ljZXMgYXBw cm9wcmlhdGUgdG8gYSBwYXJ0aWN1bGFyIHByb2ZpbGUgd2lsbCBuZWNlc3NhcmlseSBtYWtlIHRo ZW0gYSBwb29yIG9yIGltcG9zc2libGUNCiBmaXQgZm9yIG90aGVycy4mbmJzcDsgVGhpcyB3b3Vs ZCBiZSBhIHZlcnkgYmFkIHRoaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPklyb25pY2FsbHksIOKAnGxvY2tpbmcgZG93buKAnSBTRVQgdG8gcmVxdWlyZSBjaG9p Y2VzIG1vdGl2YXRlZCBieSBhIHBhcnRpY3VsYXIgcHJvZmlsZSB3b3VsZG7igJl0IGhlbHAgdGhh dCBwcm9maWxlIGF0IGFsbCwgYXMgaXQgd291bGQgd29yayB0aGUgc2FtZSB3aGV0aGVyDQogU0VU IHdhcyDigJxsb2NrZWQgZG93buKAnSBvciBub3QuJm5ic3A7IEJ1dCBpdCB3b3VsZCB1bm5lY2Vz c2FyaWx5IHByZWNsdWRlIHVzZSBvZiBTRVRzIGluIG90aGVyIGNvbnRleHRzIHRoYXQgdGhleSBh cmUgY3VycmVudGx5IGEgZ3JlYXQgZml0IGZvci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNjdXJ0 ZXNjdUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMjYs IDIwMTcgOTo0MyBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwv YT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPC9hPiZndDs7IFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ Jmd0OzsgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWNo YW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4m Z3Q7Ow0KIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t IiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OzsgSGVuayBCaXJraG9s eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRh cmdldD0iX2JsYW5rIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDs7IFlh cm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OzsNCiBJRCBFdmVudHMg TWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlz dGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3RpbiwgaW4gdGhlIGNhc2Ugd2hlbiBhbiBSUCBp cyBpc3N1aW5nIHRoZSBTRVQgdG8gc2VuZCBpdCB0byBhbiBJZFAsIGEgdG9wIGxldmVsIHN1YiBh cyB5b3UgZGVzY3JpYmUgaXQgbWF5IG5vdCBiZSBwb3NzaWJsZS4gT3IgbWF5YmUgSSBtaXN1bmRl cnN0YW5kLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PldlIGFncmVlIG9uICZxdW90O2lzcyZxdW90OyBJIHRoaW5rLCBpbiB0aGlzIGNhc2UgaXQgcG9p bnRzIHRvIHRoZSBSUC4gQSB0b3AgbGV2ZWwgJnF1b3Q7c3ViJnF1b3Q7IHRob3VnaCBpcyBwcm9i bGVtYXRpYywgVGhlIFJQIGluIG1hbnkgY2FzZXMgaGFzIHRoZSBvcGFxdWUgJnF1b3Q7c3ViJnF1 b3Q7IGFzIGlzc3VlZCBieSB0aGUgSWRQLCBidXQgdGhpcyB2YWx1ZQ0KIGlzIGdsb2JhbGx5IHVu aXF1ZSBvbmx5IHdoZW4gY29tYmluZWQgd2l0aCB0aGUgSWRQICZxdW90O2lzcyZxdW90Oy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5v dCBzdXJlIHdoeSBldmVudC5hdWQgd291bGQgYmUgbmVjZXNzYXJ5PzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEp1biAyNSwgMjAxNyBh dCA3OjMxIEFNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQu ZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD5NaWtlLCB0aGlzIGlz IG5vdCBhdCBhbGwgd2hhdCBJIHNlZSBmb3IgaGF2aW5nIHRoZSAmcXVvdDttb3N0IHN1cHBvcnQm cXVvdDsuIEluc3RlYWQgSSdtIHNlZWluZyBhIGxvdCBvZiBjYWxsIGZvciBoYXZpbmcgJnF1b3Q7 c3ViJnF1b3Q7IGRlZmluZWQgY2xlYXJseSBpbiB0aGUgZXZlbnQgcGF5bG9hZCBvbmx5LjxvOnA+ PC9vOnA+PC9wPg0KPHA+VGhlICZxdW90O3N1YiZxdW90OyBvZiB0aGUgbWFpbiBib2R5IGlzIHRo ZSBzdWJqZWN0IGFzIGtub3duIGJ5IHRoZSBpc3N1ZXIgb2YgdGhlIFNFVCBpdHNlbGYuIFRoaXMg bWlnaHQgYmUgdGhlIHNhbWUgc3ViamVjdCB0aGF0IHRoZSBzdWJqZWN0IGlzIGtub3duIGJ5IGF0 IHRoZSB0YXJnZXQgb2YgdGhlIFNFVC4gVGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgdGhpcyBp c24ndCB0cnVlLCBhbmQgc28gZmFyIG9uZSBleGNlcHRpb24gY2FzZSB3aGVyZSBpdCBpcywNCiBz b21ldGltZXMuIFdlIHNob3VsZCBub3QgYmUgd3JpdGluZyB0aGlzIGZvciB0aGUgZXhjZXB0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHA+QnV0IEkgdGhpbmsgdGhlcmUncyBhIHByZXR0eSBjbGVhciBw YXRoIGZvcndhcmQuIFRoZSAmcXVvdDtzdWImcXVvdDsgaW4gdGhlIGJvZHkgb2YgYSBTRVQsIGlm IGl0IGlzIGluY2x1ZGVkLCBpcyAqQUxXQVlTKiBpbiB0aGUgY29udGV4dCBvZiB0aGUgJnF1b3Q7 aXNzJnF1b3Q7IG9mIHRoZSBTRVQuIEFsd2F5cywgZnVsbCBzdG9wLCBubyBleGNlcHRpb25zLiBO byBnbG9iYWwgbmFtZXNwYWNlcywgbm8gcmVzdHJpY3Rpb25zIG9uIGNvbnRlbnQsIG5vIGZvcm1h dHMgLS0gaXQncw0KIGFuIG9wYXF1ZSAodG8gdGhlIFNFVCBzdGFuZGFyZCkgdmFsdWUgaW4gdGhl IGRvbWFpbiBvZiB0aGUgaXNzdWVyIG9mIHRoZSBTRVQuIDxvOnA+DQo8L286cD48L3A+DQo8cD5F dmVudCBwYXlsb2FkcywgZGVmaW5lZCBpbiBwcm9maWxlcywgZGVzY3JpYmUgYSBzdWJqZWN0IG9m IHRoZSBldmVudCBpdHNlbGYuIEltcG9ydGFudGx5LCB0aGlzIGlzIHRoZSBzdWJqZWN0IGFzIGtu b3duIGJ5IHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSBldmVudCB3aWxsIGJlICpyZWNlaXZlZCos IG5vdCBpbiB3aGljaCBpdCB3YXMgKmlzc3VlZCouIFNvbWV0aW1lcyB0aG9zZSBhcmUgdGhlIHNh bWUsIG1vcmUgb2Z0ZW4gKGFzIHdlJ3JlDQogc2VlaW5nKSB3ZSBjYW4ndCBndWFyYW50ZWUgdGhh dC4gV2Ugc2hvdWxkIG5vdCBkZXBlbmQgb24gdGhhdCBhbmQgd2Ugc2hvdWxkIG5vdCB0cmVhdCB0 aGUgZXhjZXB0aW9uYWwgY2FzZSBhcyB0aGUgdXN1YWwsIG5vIG1hdHRlciB3aGF0IHN5bnRheCBh bm90aGVyIGdyb3VwIGhhcyBjb21lIHVwIHdpdGguDQo8bzpwPjwvbzpwPjwvcD4NCjxwPlNvIGhl cmUncyB0aGUgdGhpbmcuIEkgdGhpbmsgdGhlICZxdW90O3N1YiZxdW90OyBvZiBhbiBldmVudCBz aG91bGQgYmUgb3B0aW9uYWwsIGFuZCBBTFdBWVMgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3Vl ciwgYW5kIHByb2ZpbGVzIHNob3VsZCBub3QgcGxhY2VzIGZ1cnRoZXIgY29uc3RyYWludHMgb24g dGhhdC4gRXZlbnRzIHRoZW1zZWx2ZXMgc2hvdWxkIGJlIHNlbGYtY29udGFpbmVkLiBJIHJlZ3Jl dCB0aGF0IHdlIGRpZG4ndCBtYWtlIHRoZSByZWdpc3RyYXRpb24NCiBvYmplY3QgaW4gUkZDNzU5 MSBtb3JlIHNlbGYtY29udGFpbmVkLCBhcyB0aGF0J3MgY2F1c2VkIGltcGxlbWVudGF0aW9uIGFu ZCBleHRlbnNpb24gaXNzdWVzLiBJIHRoaW5rIGV2ZW50cyBzaG91bGQgYWx3YXlzIGhhdmUgYW4g aW50ZXJuYWwgc3ViamVjdC9pc3N1ZXIgcGFpciwgaW4gdGhlIGNvbnRleHQgb2Ygd2hlcmUgdGhl IGV2ZW50IGlzIGJlaW5nIGNvbnN1bWVkLiBXZSBuZWVkIHRvIGRlZmluZSB3aGF0IGlzcy9zdWIg bWVhbiAoaW4gYSBncmFuZA0KIHNlbnNlKSBpbnNpZGUgdGhlIGV2ZW50IG9iamVjdCBpbiB0aGlz IGRvY3VtZW50LCBzbyB0aGF0IGRpZmZlcmVudCBldmVudHMgZG9uJ3QgcmVpbnZlbnQgdGhlIHNh bWUgdGhpbmcgb3ZlciBhbmQgb3Zlci4gSWYgYSBwcm9maWxlIHdhbnRzIHRvIGxlYXZlIHRoYXQg b3V0IGJlY2F1c2UgdGhleSBkb24ndCBuZWVkIGFuIGlkZW50aWZpZXIgZm9yIHRoZSBwYXlsb2Fk LCB0aGVuIHRoZXkgY2FuIGxlYXZlIGl0IG91dC4gSWYgdGhleSB3YW50IHRvIGxlYXZlDQogaXQg b3V0IGJlY2F1c2UgdGhleSB3YW50IHRvIGFzc3VtZSB0aGVyZSB3aWxsICZxdW90O2Fsd2F5cyZx dW90OyBiZSBhbiBpc3Mvc3ViIGluIHRoZSByb290IG9mIHRoZSBTRVQsIHRoZW4gSSBoYXZlIGEg cHJvYmxlbSB3aXRoIHRoYXQuIFRoZSBpc3N1ZXIgb2YgdGhlIFNFVCBjYW4sIGFuZCBwcm9iYWJs eSBkb2VzLCBoYXZlIGl0cyBvd24gaWRlbnRpZmllciB3aGljaCBjYW4ndCBiZSBhc3N1bWVkIHRv IGJlIHVuaXZlcnNhbC4gUHJvcG9zaW5nIGEgZ2xvYmFsIHN1YmplY3QNCiBuYW1lc3BhY2Ugb3Ig Zm9ybWF0LCBhcyBoYXMgYmVlbiBzdWdnZXN0ZWQgZWxzZXdoZXJlIG9uIHRoaXMgbGlzdCwgaXMg bHVkaWNyb3VzIGFuZCB3aWxsIG5ldmVyIGZseSBhcyBpdCBnb2VzIGFnYWluc3QgaG93IEpXVCBu YW1lc3BhY2luZyBmb3IgcGVvcGxlIGFuZCBvYmplY3RzIGhhcyBhbHdheXMgd29ya2VkLiBXZSBz aG91bGQgaGF2ZSBhIGNsZWFyIHNlbWFudGljIGRhdGEgc3RydWN0dXJlIHRoYXQgY2FuIGJlIGV4 dGVuZGVkIGFuZCB1c2VkDQogYnkgYWxsIG9mIHRoZSB1c2UgY2FzZXMgdGhhdCB3ZSd2ZSBhZG9w dGVkLiBPcHRpbWl6aW5nIGF0IHRoaXMgc3RhZ2UsIGVzcGVjaWFsbHkgYmFzZWQgb24gb25lIGV2 ZW50LCBpcyBnb2luZyB0byBqdXN0IGxlYWQgdG8gdGhpbmdzIGJlaW5nIGJyb2tlbiBhbmQgYmFj ay1wYXRjaGVkIGxhdGVyIG9uLiBCdXQgaWYgb25lIHNwZWMgd2FudHMgdG8gbGVhdmUgb3V0IHRo ZSBpc3Mvc3ViIGluc2lkZSB0aGUgZXZlbnQ/IFRoZXkgY2FuIHN0aWxsIGRvDQogdGhhdCwgYnV0 IEkgdGhpbmsgdGhhdCdzIHByZXR0eSBkYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD5JbiBzdW1tYXJ5OjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KaXNzOiBpc3N1ZXIgb2YgdGhlIGV2ZW50PG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCnN1Yjogc3ViamVjdCBvZiB0aGUgZXZlbnQgYXMga25vd24gYnkgdGhlIGlzc3VlciBv ZiB0aGUgZXZlbnQ8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KZXZlbnQuc3ViOiBzdWJqZWN0IG9m IHRoZSBldmVudCBhcyBrbm93biBieSB0aGUgcmVjaXBpZW50IG9mIHRoZSBldmVudDxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQpldmVudC5pc3M6IGNvbnRleHQgZm9yIHRoZSBzdWJqZWN0IG9mIHRo ZSBldmVudCBhcyBrbm93biBieSB0aGUgcmVjaXBpZW50IG9mIHRoZSBldmVudDxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQpldmVudC5hdWQ6IHJlY2lwaWVudCBvZiB0aGUgZXZlbnQ8bzpwPjwvbzpw PjwvbGk+PC91bD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7LS0gSnVzdGlu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gNi8yMS8yMDE3IDc6NDUgUE0s IE1pa2UgSm9uZXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHByb3Bv c2FsIHRoYXQgSSBiZWxpZXZlIGhhcyB0aGUgbW9zdCBzdXBwb3J0IGlzIGtlZXBpbmcgdGhpbmdz IGFzIHRoZXkgYXJlLCBsZWF2aW5nIGl0IHVwIHRvIHByb2ZpbGVzIGFuZCBhcHBsaWNhdGlvbnMg dG8gZGVmaW5lIHdoaWNoIGNsYWltcyB0aGV5IHVzZSBhbmQgaG93IHRoZXkgdXNlIHRoZW0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCB3b3VsZCBiZSBmaW5lIGZvciBzb21lIHByb2Zp bGVzIHRvIHVzZSB0aGUgbGFuZ3VhZ2UgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij7igJMgTWlrZTxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlBoaWwgSHVudDwvYT48YnI+DQo8Yj5TZW50 OiA8L2I+V2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IDY6MzkgUE08YnI+DQo8Yj5UbzogPC9iPjxh IGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+UmljaGFy ZCBCYWNrbWFuLCBBbm5hYmVsbGU8L2E+PGJyPg0KPGI+Q2M6IDwvYj48YSBocmVmPSJtYWlsdG86 bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWFyaXVzIFNjdXJ0ZXNjdTwv YT47DQo8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj5K b2huIEJyYWRsZXk8L2E+OyA8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5o b2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPg0KSGVuayBCaXJraG9sejwvYT47IDxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5KdXN0aW4gUmljaGVyPC9hPjsN CjxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5Z YXJvbiBTaGVmZmVyPC9hPjsgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KTWlrZSBKb25lczwvYT47IDxhIGhyZWY9Im1haWx0bzpp ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklEIEV2ZW50cyBNYWlsaW5nIExpc3Q8 L2E+PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9B Y2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5TbyBJIHVuZGVyc3RhbmQgd2hhdCBpcyBiZWluZyBwcm9wb3Nl ZCBpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ SWYgdGhlIGV2ZW50IHR5cGUgdXNlcyDigJxzdWLigJ0gdG8gaWRlbnRpZnkgaXRzIHN1YmplY3Qs IGFuZCB0aGUgaXNzdWVyIG9mIHRoZSBzdWJqZWN0IGlzIGlkZW50aWNhbCB0byB0aGUgaXNzdWVy IGZvciB0aGUgZXZlbnQsIHRoZW4g4oCcc3Vi4oCdDQogbWF5IGJlIHVzZWQgYXQgdGhlIHRvcCBs ZXZlbC4gT3RoZXJ3aXNlLCB0aGUgc3ViamVjdCBvZiBhbiBldmVudCAoZS5nLiDigJxzdWLigJ0p IGFuZCBhbnkgb3RoZXIgY2xhaW1zIHJlcXVpcmVkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBz dWJqZWN0IE1VU1QgYmUgY29udGFpbmVkIGluIHRoZSBldmVudCBwYXlsb2FkLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZv ciBleGFtcGxlLCBhbiBpcCBhZGRyZXNzIG9mIDEuMi4zLjQgbWlnaHQgYmUgcmVwcmVzZW50ZWQg aW4gYSDigJxpcGFkZHJlc3PigJ0gY2xhaW0gZGVmaW5lZCBpbiB0aGUgZXZlbnQgcGF5bG9hZC4g 4oCcaXBhZGRyZXNz4oCdOuKAnTEuMi4zLjQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QSBTQ0lNIHJlc291cmNlIFVSSSBvZg0KPGEg aHJlZj0iaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL3VzZXJzL2FjMWZhZWJiZmQzYzQ1Y2U5YTI0 MmJkMzg1OWM4MmM0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3NjaW0uZXhhbXBsZS5jb20v dXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5YzgyYzQ8L2E+IG1pZ2h0IGJlIGlkZW50 aWZpZWQgaW4gdGhlIGV2ZW50IHBheWxvYWQgYXM6IOKAnHN1YuKAnTomcXVvdDs8YSBocmVmPSJo dHRwczovL3NjaW0uZXhhbXBsZS5jb20vdXNlcnMvYWMxZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5 YzgyYzQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3NjaW0uZXhhbXBsZS5jb20vdXNlcnMvYWMx ZmFlYmJmZDNjNDVjZTlhMjQyYmQzODU5YzgyYzQ8L2E+4oCdPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BIENvbm5lY3QgTG9nb3V0IGV2 ZW50IGZyb20gYW4gT1AgdXNlcyB0aGUgdG9wIGxldmVsIHN1YiBjbGFpbSBhbmQgZGVwZW5kcyBv biDigJxpc3PigJ0gYmVpbmcgdGhlIHNhbWUgZm9yIHRoZSBldmVudCBpc3N1ZXIgQU5EIHRoZSBz dWJqZWN0LiBUaGlzIG1lYW5zIHRoYXQgbm8gcGFydHkgbWF5IGlzc3VlIGxvZ291dA0KIGV2ZW50 cyBvbiBiZWhhbGYgb2YgdGhlIE9QLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PcmFjbGUgQ29y cG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdCAmYW1wOyBTdGFuZGFy ZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBKdW4gMjEsIDIwMTcsIGF0IDM6MzggUE0sIFJpY2hhcmQgQmFja21h biwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCkZhaXIgcG9pbnQuIElmIHdl IGRvIG5vdCBpbnRlbmQgdG8gc3VwcG9ydCBtdWx0aXBsZSBwcm9maWxlcyB3aXRoaW4gYSBzaW5n bGUgU0VULCB0aGVuIEnigJltIGxlc3MgY29uY2VybmVkIGFib3V0IGxlYXZpbmcgc3ViIHNlbWFu dGljcyB1cCB0byB0aGUgcHJvZmlsZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JZGVudGl0eSBTZXJ2aWNl czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEz MTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk1hcml1cyBT Y3VydGVzY3UgJmx0OzxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNw YW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldlZG5lc2RheSwgSnVuZSAyMSwgMjAx NyBhdCAyOjU4IFBNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4 bS02NjU2OTcyOTQzNjg1MzQyMTI1YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPiZxdW90O1JpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpY2hhbm5hQGFtYXpv bi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3 OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjwvYj4mcXVvdDtQaGlsIEh1bnQgKElETSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9h PiZndDssIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t IiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OywNCiBIZW5rIEJpcmto b2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIg dGFyZ2V0PSJfYmxhbmsiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L2E+Jmd0Oywg SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0 PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7LCBZYXJvbiBTaGVmZmVyICZsdDs8YSBo cmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25m LmlldGZAZ21haWwuY29tPC9hPiZndDssDQogTWljaGFlbCBKb25lcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7LCBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8 YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVu dEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0ibTg0MDE3MTY1 MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+UmU6IFtJZC1ldmVudF0gc29sdXRpb24gZm9yIElkL0FjY2VzcyBUb2tl biBjb25mdXNpb24gYW5kIGRpc3RpbmN0IFNFVCBpc3N1ZXI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+RXhhbXBsZSBmb3Ig bXVsdGlwbGUgZXZlbnRzIHdpdGhpbiBzYW1lIHByb2ZpbGU6IElkUCBhY2NvdW50IGlzIGRpc2Fi bGVkIChiZWNhdXNlIG9mIGhpamFja2luZyksIHRoaXMgY2FuIGxlYWQgdG8gdHdvIGV2ZW50czo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4xLiAmcXVv dDthY2NvdW50LWRpc2FibGVkJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4yLiAmcXVvdDtzZXNzaW9ucy1yZXZva2VkJnF1b3Q7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnIgY2xlYXI9ImFsbCI+DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+TWFyaXVzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5PbiBXZWQsIEp1biAyMSwgMjAxNyBhdCAyOjU0IFBNLCBSaWNoYXJkIEJhY2tt YW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpUaGUgc3BlYyBzYXlzIHRoYXQgdGhlIGV2ZW50 cyBjbGFpbSBTSE9VTEQgTk9UIGJlIHVzZWQgdG8gZXhwcmVzcyBtdWx0aXBsZSBsb2dpY2FsIGV2 ZW50cy4gSWYgaXTigJlzIGFsc28gbm90IHVzZWQgdG8gZXhwcmVzcyBldmVudHMgZnJvbSBkaWZm ZXJlbnQgcHJvZmlsZXMgdGhhdCBjb3JyZXNwb25kIHRvIHRoZSBzYW1lIGxvZ2ljYWwgZXZlbnQg KGUuZy4gYW4gT0lEQyBiYWNrY2hhbm5lbCBsb2dvdXQgZXZlbnQgYWxvbmdzaWRlIGEgaHlwb3Ro ZXRpY2FsDQogUklTQyBsb2dvdXQgZXZlbnQpLCB0aGVuIEnigJltIG5vdCBzdXJlIHdoYXQgdXNl IGNhc2UgdGhhdCBsZWF2ZXMgZm9yIG11bHRpcGxlIGV2ZW50cyBpbiBvbmUgU0VULjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbm5hYmVs bGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+SWRlbnRpdHkgU2VydmljZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5Gcm9tOjxzcGFuIGNs YXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNWFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdCI+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiAmcXVvdDtQ aGlsIEh1bnQgKElETSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0ibTg0 MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5LCBKdW5lIDIxLCAyMDE3IGF0IDI6MTIgUE08 YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2 ODUzNDIxMjVhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Sm9obiBCcmFk bGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52ZTdqdGJAdmU3anRiLmNvbTwvc3Bhbj48L2E+ Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3 Mjk0MzY4NTM0MjEyNWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVv dDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJp Y2hhbm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7LCBIZW5rIEJpcmtob2x6ICZs dDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlbmsuYmlya2hvbHpAc2l0LmZy YXVuaG9mZXIuZGU8L3NwYW4+PC9hPiZndDssDQogSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmpyaWNoZXJAbWl0LmVkdTwvc3Bhbj48L2E+Jmd0OywgTWFyaXVzIFNjdXJ0ZXNj dSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bh bj48L2E+Jmd0OywgWWFyb24NCiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7LCBNaWNoYWVsIEpvbmVzICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PC9zcGFuPjwvYT4mZ3Q7LA0KIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0OzxhIGhyZWY9Im1h aWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0 OjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNWFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBzb2x1 dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vl cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlNlcGFyYXRlIG9yIGNvbWJpbmVkIG1heSBiZSBldm9sdmluZy4gTWlrZSB3YW50 cyB0byBrZWVwIHRoZSBjdXJyZW50IGJhY2tjaGFubmVsIGxvZ291dCB2ZXJ5IG5hcnJvd2x5IHNj b3BlZC4gSGUgc3VnZ2VzdGVkIHJpc2MgZGVmaW5lIGl0cyBvd24gZHVwbGljYXRlIGRlZmluaXRp b25zIGFuZCBtZWFuaW5ncy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBpZD0ibV84NDAxNzE2NTI4MTMxMTI5ODc4bV8tNjY1Njk3Mjk0MzY4NTM0MjEy NW1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzg0 MDE3MTY1MjgxMzExMjk4NzhtXy02NjU2OTcyOTQzNjg1MzQyMTI1bV8tNDYyOTg0MjU2OTM4NTE1 OTk4OEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBsZWFkcyBtZSB0byBiZWxp ZXZlIHdlIHdpbGwgaGF2ZSBtdWx0aS10eXBlIGV2ZW50cyBpbiBwcmFjdGljZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV84NDAxNzE2NTI4MTMxMTI5 ODc4bV8tNjY1Njk3Mjk0MzY4NTM0MjEyNW1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxT aWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzg0MDE3MTY1MjgxMzExMjk4NzhtXy02NjU2OTcyOTQzNjg1 MzQyMTI1bV8tNDYyOTg0MjU2OTM4NTE1OTk4OEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+U2Vzc2lvbiBjYW5jZWxsYXRpb24gY2FuIG9jY3VyIGZvciBtYW55IHJlYXNvbnMuIE9uZSBv ZiB0aGUgZGlmZmVyZW50aWF0b3JzIHdlIGhhZCB0cmllZCB0byBtYWtlIHdhcyBhbiBhc3N1bXB0 aW9uIHRoYXQgdXNlciBpbml0aWF0ZWQgZXZlbnRzIHdvdWxkIGJlIHBhcnQgb2YgY29ubmVjdC4g UmlzayB3b3VsZCBjb3ZlciB2YXJpYXRpb25zDQogdGhhdCBkcml2ZSBvZmYgb2YgcmlzayBjYWxj dWxhdGlvbnMgbGlrZSBwYXNzd29yZCByZXNldC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV84NDAxNzE2NTI4MTMxMTI5ODc4bV8tNjY1Njk3 Mjk0MzY4NTM0MjEyNW1fLTQ2Mjk4NDI1NjkzODUxNTk5ODhBcHBsZU1haWxTaWduYXR1cmUiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGlkPSJtXzg0MDE3MTY1MjgxMzExMjk4NzhtXy02NjU2OTcyOTQzNjg1MzQyMTI1bV8tNDYy OTg0MjU2OTM4NTE1OTk4OEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgYXJl IGFsc28gc2lnbm91dCBldmVudHMgYXQgcnAncyB0byBsZXQgdGhlIE9QIGtub3cuIFRoZXNlIGFy ZSBub3QgY29tbWFuZHMgYnV0IG5vdGlmaWNhdGlvbiB0aGF0IGEgcmVzb3VyY2Ugc2Vzc2lvbiBp cyBjYW5jZWxsZWQuIElPVyBzaW5nbGUgc2lnbiBvdXQgbm90IGV4cGVjdGVkLiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzg0MDE3MTY1Mjgx MzExMjk4NzhtXy02NjU2OTcyOTQzNjg1MzQyMTI1bV8tNDYyOTg0MjU2OTM4NTE1OTk4OEFwcGxl TWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KUGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQpPbiBKdW4gMjEsIDIwMTcsIGF0IDE6NTgg UE0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dmU3anRiQHZlN2p0Yi5j b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JIHRob3Vn aHQgd2UgZGVjaWRlZCB0aGF0IHdlIGFyZSBvbmx5IGFsbG93aW5nIHNldCBtZXNzYWdlcyBmb3Jt IHRoZSBzYW1lIGZhbWlseSB0aGF0IGFncmVlIG9uIHRvcCBsZXZlbCBjbGFpbXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5PdGhlcndp c2UgdGhlcmUgY2FuIGJlIG5vIHRvcCBsZXZlbCBjbGFpbXMgYW5kIHdlIGFyZSByZWFsbHkgZGVm aW5pbmcgYSBhbHRlcm5hdGl2ZSBmb3JtYXQgdG8gSldUIGluIHNvbWUgd2F5cy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ Sm9obiBCLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEp1biAyMSwg MjAxNywgYXQgMzo1NCBQTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9 Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+cmljaGFubmFAYW1hem9uLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KSSBhZ3JlZSB3aXRoIEpvaG4gdGhhdCB0aGUgSldUIHR5cGUgY29uZnVzaW9uIHBy b2JsZW0gYW5kIHRoZSBTRVQgc3ViIHByb2JsZW0gY2FuIGFuZCBzaG91bGQgYmUgZGlzY3Vzc2Vk IHNlcGFyYXRlbHkuIFRoZSBzZWNldmVudHMgV0cgaXMgcHJvYmFibHkgbm90IHRoZSByaWdodCBz ZXR0aW5nIHRvIGRpc2N1c3MgdGhlIGZvcm1lci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KTXkgY29uY2VybiB3aXRo IHRoZSBzdWIgY2xhaW0gaXMgdGhhdCB0d28gcHJvZmlsZXMgbWF5IGRpY3RhdGUgY29uZmxpY3Rp bmcgc2VtYW50aWNzIChlLmcuIFByb2ZpbGUgQSBzYXlzIGl04oCZcyBhIHBob25lIG51bWJlciwg UHJvZmlsZSBCIHNheXMgaXTigJlzIGFuIGVtYWlsIGFkZHJlc3MpLiBJZiB0aGVzZSBwcm9maWxl cyBkb27igJl0IHByb3ZpZGUgYW4gYWx0ZXJuYXRlIHdheSB0byBkZWNsYXJlIHN1YmplY3Qgb2Yg dGhlaXIgZXZlbnRzLCB0aGVuIHRoZXkNCiBjYW5ub3QgYmUgcHJlc2VudCB3aXRoaW4gdGhlIHNh bWUgdG9rZW4uIFRoaXMgaW5jb21wYXRpYmlsaXR5IHRyYXAgc2VlbXMgbGlrZSBzb21ldGhpbmcg dGhhdCBjb3VsZCBiZSBlYXNpbHkgbWlzc2VkIGJ5IGdyb3VwcyBwcm9maWxpbmcgU0VULjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbm5hYmVsbGUgUmljaGFy ZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+SWRlbnRpdHkgU2VydmljZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJt ODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1 OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Sm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86 dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj52ZTdqdGJAdmU3anRiLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4g Y2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQy NTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldlZG5l c2RheSwgSnVuZSAyMSwgMjAxNyBhdCAxOjM5IFBNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9Im04 NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5 OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+ PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2 NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmpyaWNoZXJAbWl0LmVkdTwvc3Bhbj48L2E+Jmd0OywgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0 OywNCiBBbm5hYmVsbGUgUmljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpv bi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yaWNoYW5u YUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7LCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7LA0KIE1pY2hhZWwg Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDssIElEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0Ozxh IGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7LA0KIEhl bmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhv ZmVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVuay5i aXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00 NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVzaW9uIGFu ZCBkaXN0aW5jdCBTRVQgaXNzdWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkluIHRo ZSBlbnZlbG9wZSB0eXAgaXMgYSBtZWRpYS9taW1lIHR5cGUuJm5ic3A7IFJlZ2lzdGVyaW5nIGFw cGxpY2F0aW9uL2lkdCYjNDM7and0IGlmIHdlIHJlZ2lzdGVyIGp3dCBhcyBhIHN0cnVjdHVyZWQg bmFtZSBzdWZpeC4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlVzaW5nIHRoZSBj dHkgaXMgYWxzbyBwb3NzaWJsZS4gJm5ic3A7IEkgbmVlZCB0byB0aGluayBhYm91dCB3aGF0IGlz IGJldHRlciBidXQgd2UgY2FuIGFncmVlIG9uIGEgY29udmVudGlvbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Tm90IGV2ZXJ5dGhpbmcgaXMgZ29pbmcgdG8gYmUgYSBzZXQgdG9rZW4gbGlrZSBub3QgZXZlcnkg SldTIGlzIGEgSldULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIHdlIGFy ZSBnb2luZyB0byBkZWZpbmUgcHJvY2Vzc2luZyBydWxlcyB0byBzdG9wIGNvbGxpc2lvbnMgYW5k IGNvbmZ1c2lvbiBhcm91bmQgSldUIGZvciBkaWZmZXJlbnQgcHVycG9zZXMsIHdlIHNob3VsZCBq dXN0IHN0YXJ0IHVzaW5nIHRoZSB0eXAgcGFyYW1ldGVyIGJhc2VkIG9uIHRoZSBleGlzdGluZyBz cGVjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGdlbmVyYWwgY29udGVu dCBzbmlmZmluZyBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIG9wdGlvbiBldmVudHVhbGx5IGdl dHMgeW91IGludG8gdHJvdWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J IGFtIG5vdCBjb252aW5jZWQgdGhhdCBmb3JjaW5nIHRoZXJlIHRvIGJlIG5vIHN1YiBhdCB0aGUg dG9wIGxldmVsIGlzIGEgZ29vZCBpZGVhLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCBpcyBub3QgdGhlIHdh eSB3ZSBzaG91bGQgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIFNFVCBhbmQgaWRfdG9rZW5zLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SWYgc3ViIGlzIG5vdCBhbGxvd2VkIGF0IHRoZSB0 b3AgbGV2ZWwgcGVvcGxlIHdpbGwgZG8gbm9uIFNFVCBKV1QgZm9yIHRoaW5ncyB3aGVyZSB0aGUg c3ViamVjdCBpcyBzY29wZWQgdG8gdGhlIGlzcyBvZiB0aGUgdG9rZW4uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkkgdGhpbmsgZGVmaW5pbmcgc3ViIHRvIGJlIHBhcnQg b2YgdGhlIGV2ZW50IGZvciBjYXNlcyB3aGVyZSB0aGUgc3ViIGlzIHNjb3BlZCBkaWZmZXJlbnRs eSBmcm9tIHRoZSBpc3N1ZXIgb2YgdGhlIHRva2VuIGlzIGZpbmUsIGJ1dCBzaG91bGQgbm90IGJl IHJlcXVpcmVkIGZvciBhbGwgZXZlbnQgdHlwZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPkkgdGhpbmsgd2Ugc2hvdWxkIHNvbHZlIHRoZSBjb25mdXNpb24gaXNzdWUg c2VwYXJhdGVseSBmcm9tIHRoZSBzdWIgaXNzdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPlNvcnJ5IEkgYW0gYXQgQ0lTIHNvIHRyeWluZyB0byBjYXRjaCB1cCBvbiBs aXN0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Sm9obiBCLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIEp1biAxNywgMjAxNywgYXQgMzo0NSBQTSwgWWFyb24gU2hlZmZlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+U28gdG8gc3VtbWFyaXplIHdoYXQgSSdtIHNlZWluZyBvbiB0aGlzIHRocmVhZDo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5F dmVyeWJvZHkgYWdyZWVzIHdpdGggTWFyaXVzJ3Mgc2hvcnQtdGVybSBzb2x1dGlvbiwgc3BlY2lm aWMgcnVsZXMgZm9yICZxdW90O3N1YiZxdW90OyBhbmQgJnF1b3Q7aXNzJnF1b3Q7IHRoYXQgY2Fu IGJlIGRlZmluZWQgaW4gdGhlIFNFVCBzcGVjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsbW9zdCBldmVyeWJvZHkgYWdyZWVzIG9uIGEg bG9uZy10ZXJtICZxdW90O3VzYWdlJnF1b3Q7IGNsYWltICgmcXVvdDt0eXBlJnF1b3Q7IGlzIHRh a2VuKSB0aGF0IHNob3VsZCBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgZS5nLiBpbiB0aGUgSldUIEJD UC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5EaWQgSSBtaXNzIGFueXRoaW5nPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJ5IHRoZSB3YXksIGlmIHdlIGRvIGFkZCBhICZxdW90O3Vz YWdlJnF1b3Q7IGNsYWltLCB3ZSBuZWVkIHRvIGFsc28gdXNlIGl0IGluIHRoZSBTRVQgZG9jdW1l bnQgYmVmb3JlIGl0IGlzIHB1Ymxpc2hlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPk9uIDE1LzA2LzE3IDIyOjA4LCBKdXN0aW4gUmljaGVyIHdyb3RlOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mIzQzOzEgdG8gdGhpcyBhcyB3ZWxs LjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0t NDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDvigJQgSnVzdGluPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEp1 biAxNSwgMjAxNywgYXQgMTowOSBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ JiM0MzsxIHRvIHdoYXQgQW5uYWJlbGxlIHNhaWQuPHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMx MTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFs c28sIE1pa2UgeW91IGFyZSBtaXNzaW5nIHRoZSBvdGhlciByZXF1aXJlbWVudCwgZm9yIFJQcyB0 byBzZW5kIGV2ZW50cyB0byBhbiBJZFAuIFRoZSBpc3MmIzQzO3N1YiBwYWlyIGF0IHRoZSB0b3Ag bGV2ZWwgaXMgYnJva2VuIGluIHRoaXMgY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48YnIgY2xlYXI9ImFsbCI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1hcml1czwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEp1biAxNCwgMjAxNyBh dCA1OjMzIFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBo aWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+JiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV84NDAxNzE2NTI4MTMxMTI5ODc4bV8tNjY1Njk3Mjk0MzY4NTM0MjEyNW1f LTQ2Mjk4NDI1NjkzODUxNTk5ODhtXzkwOTQwODkyMzk2Njg1NzAzMTJBcHBsZU1haWxTaWduYXR1 cmUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzg0MDE3MTY1MjgxMzExMjk4NzhtXy02NjU2 OTcyOTQzNjg1MzQyMTI1bV8tNDYyOTg0MjU2OTM4NTE1OTk4OG1fOTA5NDA4OTIzOTY2ODU3MDMx MkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlBoaWw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5P biBKdW4gMTQsIDIwMTcsIGF0IDU6MjUgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZs dDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJpY2hhbm5hQGFtYXpvbi5jb208L3NwYW4+PC9hPiZn dDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCk1pa2UsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCllvdXIgZXhwbGFuYXRpb24gZm9yIHdoeSB0aGlzIGlzIGEgbm9uLXByb2Js ZW0gaXMgZGVwZW5kZW50IHVwb24gc2lkZSBlZmZlY3RzIG9mIGVsZW1lbnRzIG9mIE9wZW5JRCBD b25uZWN0IHRoYXQgd2VyZSBub3QgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4gQXMgYSBy ZXN1bHQsIEkgc2VlIHNldmVyYWwgaXNzdWVzIHdpdGggaXQ6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1 MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFy YWdyYXBoIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+DQoxLjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtODQwMTcxNjUy ODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5UaGUgY2FsbGVyIG9mIHRoZSBU b2tlbiBFbmRwb2ludCBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IGNhbiBiZSBjZXJ0YWluDQogdGhh dCBhIG5vbmNlLWxlc3MgSUQgVG9rZW4gaXMgcmVhbGx5IGFuIElEIFRva2VuLiBBbnkgcGFydHkg dGhhdCB0aGUgY2FsbGVyIHBhc3NlcyB0aGUgSUQgVG9rZW4gb2ZmIHRvIGhhcyBubyB3YXkgdG8g dmVyaWZ5IGl0cyBwcm92ZW5hbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04NDAxNzE2 NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkw OTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+DQoyLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEy NW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj5BbnkgZnV0dXJlIElEIFRva2VuIGRpc3RyaWJ1dGlvbiBtZXRob2QgbmVlZHMgdG8g c29sdmUgdGhpcyBwcm9ibGVtIGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04NDAx NzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4 bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4zLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibTg0MDE3 MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+Tm8gb3RoZXIgcHJvZmls ZSBvZiBKV1QgY2FuIGV2ZXIgdXNlDQogdGhlICZxdW90O25vbmNl4oCdIGNsYWltLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQy MTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4bTkwOTQwODkyMzk2Njg1NzAzMTJtc29saXN0cGFyYWdy YXBoIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0Ij40Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIx MjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+VGhpcyBpcyBvbmx5IGEgc29sdXRpb24gZm9yIElEIFRva2Vucy4NCiBFdmVyeSBv dGhlciBKV1QgcHJvZmlsZSB0aGF0IGNhcmVzIGFib3V0IGRpc2FtYmlndWF0aW9uIGhhcyB0byBp bnZlbnQgaXRzIG93biBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQpXZSBrbm93 IGZyb20gZXhwZXJpZW5jZSB0aGF0IG5hbWluZyBjb2xsaXNpb25zIGFuZCByZXBsYXkgYXR0YWNr cyBhcmUgYm90aCB0aGluZ3MgdGhhdCBoYXBwZW4uIFdoYXTigJlzIGJlaW5nIHByb3Bvc2VkIGlz IGEgc2ltcGxlLCBkZWZlbnNpdmUgbWVhc3VyZSBhZ2FpbnN0IHRoZXNlIHJpc2tzLiBZb3UgYnJv dWdodCB1cCBKV1QgbGlicmFyaWVzOiBhIGdlbmVyYWwgc29sdXRpb24gYWN0dWFsbHkgbWFrZXMg aXQgZWFzaWVyIHRvIHVzZSBjb21tb24NCiBsaWJyYXJpZXMgZm9yIEpXVCBwYXJzaW5nLiBBIOKA nHVzYWdlLWF3YXJl4oCdIEpXVCBsaWJyYXJ5IGNvdWxkIGhhbmRsZSBkaXNhbWJpZ3VhdGlvbiBm b3IgYW55IEpXVCBwcm9maWxlLCB3aGVyZWFzIHdpdGggdGhlIHN0YXR1cyBxdW8gZWFjaCBwcm9m aWxlIHdvdWxkIHJlcXVpcmUgdW5pcXVlIGxvZ2ljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+SWRlbnRpdHkgU2VydmljZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4 NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+SWQtZXZlbnQg Jmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2 NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5LCBKdW5lIDE0LCAyMDE3IGF0IDE6MTYgUE08 YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2 ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+TWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVz Y3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNs YXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2 OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDtS aWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hh bm5hQGFtYXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5yaWNoYW5uYUBhbWF6b24uY29tPC9zcGFuPjwvYT4mZ3Q7LA0KIElEIEV2ZW50cyBNYWlsaW5n IExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7LCBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBz aXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L3NwYW4+PC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4 NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNv bmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojMDAyMDYwIj5Zb3XigJl2ZSBoZWFy ZCBvZiDigJxwcmVtYXR1cmUgb3B0aW1pemF0aW9u4oCdLiZuYnNwOyBJ4oCZZCBjaGFyYWN0ZXJp emUgdGhlIHByb3Bvc2FscyBpbiB0aGlzIHRocmVhZCBhcyDigJxwcmVtYXR1cmUgcGVzc2ltYXRp b27igJ0g4oCTIG1ha2luZyB0aGluZ3MgdGhhdCBjYW4gYW5kIHNob3VsZCBiZSBzaW1wbGUgY29t cGxleCwgd2l0aG91dCBkYXRhIHNob3dpbmcgdGhlcmXigJlzIGFueSBuZWVkIHRvIGRvDQogc28u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2NvbG9yOiMwMDIwNjAiPk1hbmRhdG9yeSBzb2x1dGlvbnMgYXJlIGJlaW5nIHByb3Bvc2VkIGlu IHRoaXMgdGhyZWFkIHRvIHByb2JsZW1zIHRoYXQgdGhlcmXigJlzIG5vIGV2aWRlbmNlIHRoYXQg d2UgYWN0dWFsbHkgZXZlbiBoYXZlLiZuYnNwOyBJdOKAmXMgYWxyZWFkeSBiZWVuIGVzdGFibGlz aGVkIHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgU0VUIHRvIGJlIGNvbmZ1c2VkIGZvciBh biBJRCBUb2tlbiDigJMNCiBzZWU8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2 NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfaWQt MkRldmVudF9jdXJyZW50X21zZzAwNDI4Lmh0bWwmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2 WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPWVLTFRRUG1ZclYzVGhmRGJuOTBTQ3M1NVVST1RQ aW5fbGdjNlJkcjVYb3cmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9j dXJyZW50L21zZzAwNDI4Lmh0bWw8L3NwYW4+PC9hPi4mbmJzcDsNCiBJZiBwZW9wbGUgaGF2ZSBk YXRhIHNob3dpbmcgdGhhdCB0aGlzIGlzIHBvc3NpYmxlIHdpdGggc3BlY2lmaWMga2luZHMgb2Yg QWNjZXNzIFRva2VucyBvciBvdGhlciByZWFsIEpXVCBkZXBsb3ltZW50cywgcGxlYXNlIHByb3Zp ZGUgc3BlY2lmaWNzLCBzbyB0aGF0IHdlIGNhbiB1c2UgdGhhdCBkYXRhIHRvIGluZm9ybSBhcHBy b3ByaWF0ZSBlbmdpbmVlcmluZyBjaG9pY2VzIG9uIG91ciBwYXJ0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojMDAyMDYwIj5U aGUgcHJvcG9zZWQg4oCcc29sdXRpb25z4oCdLCBzdWNoIGFzIHByb2hpYml0aW5nIHRoZSB1c2Ug b2Yg4oCcc3Vi4oCdIGluIHRoZSBub3JtYWwgd2F5LCBvciByZXF1aXJpbmcgYSB0eXBlIGNsYWlt LCB3b3VsZCBtYWtlIHByZXZpb3VzbHkgc2ltcGxlIHRoaW5ncyB1bm5lY2Vzc2FyaWx5IGNvbXBs ZXguJm5ic3A7IFllcywgdGhlbiB0aGUgcmVzdWx0IGlzIHRoZW4gZGlmZmVyZW50IHRoYW4NCiBh IG5vcm1hbCBKV1QgYnV0IGEgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGN1c3RvbSBwYXJz aW5nIGNvZGUgd291bGQgaGF2ZSB0byBiZSB1c2VkLCByYXRoZXIgdGhhbiBhIHN0YW5kYXJkIEpX VCBwYXJzZXIuJm5ic3A7IFRoZSBtb3JlIHVud2llbGR5IHdlIG1ha2UgaXQgdG8gdXNlIFNFVHMs IHRoZSBtb3JlIGxpa2VseSBkZXZlbG9wZXJzIGFyZSB0byBqdXN0IGNyZWF0ZSB0aGVpciBvd24g ZGF0YSBzdHJ1Y3R1cmVzLiZuYnNwOyBLZWVwaW5nIGl0IHNpbXBsZQ0KIGlzIHRoZSBrZXkgdG8g YWRvcHRpb24uJm5ic3A7IFN0YW5kYXJkcyBhcmUgb25seSB1c2VmdWwgaWYgdGhleSBhcmUgYWN0 dWFsbHkgdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJt ODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1 OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklkLWV2ZW50IFs8YSBocmVm PSJtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9z cGFuPjwvYT5dPHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1 MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4Nzht LTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+DQo8 Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2 ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5UdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MzMgUE08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9 Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1 MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWFyaXVzIFNjdXJ0ZXNj dSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bh bj48L2E+Jmd0OzsNCiBIZW5rIEJpcmtob2x6ICZsdDs8YSBocmVmPSJtYWlsdG86aGVuay5iaXJr aG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcy OTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+SUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlk LWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2 Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTog W0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNzIFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlz dGluY3QgU0VUIGlzc3VlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCkVjaG9pbmcgTWFyaXVz4oCZcyBxdWVzdGlvbjog Y2FuIHlvdSBleHBsYWluIHdoYXQgeW91IG1lYW4gYnkg4oCcaW50ZW5k4oCdPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFj a2dyb3VuZDp3aGl0ZSI+DQpUbyB5b3VyIGZpcnN0IHF1ZXN0aW9uLCBJIHRoaW5rIGEgYmV0dGVy IGFuYWxvZ3kgd291bGQgYmUgdGhlIFguNTA5IEtleSBVc2FnZSBleHRlbnNpb246IGEgbXVsdGkt dmFsdWVkIHByb3BlcnR5IHRoYXQgZGVjbGFyZXMgdGhlIGludGVuZGVkIHB1cnBvc2Ugb2YgdGhl IEpXVCwgYW5kIHRoYXQgYSByZWNpcGllbnQgbWF5IHJlZmVyIHRvIHdoZW4gZGV0ZXJtaW5pbmcg d2hldGhlciB0byBhY2NlcHQgYSBKV1QgYmVpbmcgcHJlc2VudGVkIHRvIGl0DQogaW4gc29tZSBj b250ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWRlbnRpdHkgU2VydmljZXM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0 ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJt ODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1 OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+SWQtZXZlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzppZC1l dmVudC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ow0KIG9uIGJl aGFsZiBvZiBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNj dXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFz cz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1Njkz ODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwg SnVuZSAxMywgMjAxNyBhdCAxMTowNSBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJtODQwMTcx NjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5IZW5rIEJpcmtob2x6ICZsdDs8 YSBocmVmPSJtYWlsdG86aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlbmsuYmlya2hvbHpAc2l0LmZyYXVu aG9mZXIuZGU8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0ibTg0MDE3MTY1 MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+SUQgRXZlbnRzIE1haWxpbmcgTGlz dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1 Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBzb2x1dGlvbiBmb3IgSWQvQWNjZXNz IFRva2VuIGNvbmZ1c2lvbiBhbmQgZGlzdGluY3QgU0VUIGlzc3Vlcjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gVHVlLCBK dW4gMTMsIDIwMTcgYXQgMjoxMSBBTSwgSGVuayBCaXJraG9seiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QW5kIGEgMm5kIHF1ZXN0aW9uLjxicj4NCjxicj4NCldoYXQgc2VtYW50aWNzIHdv dWxkICZxdW90O3VzYWdlJnF1b3Q7IHByb3ZpZGUgdGhhdCB0aGF0IGFyZSBub3QgY292ZXJlZCB2 aWEgJnF1b3Q7aW50ZW5kJnF1b3Q7LCAmcXVvdDthdWRpZW5jZSZxdW90OywgYW5kICZxdW90O3Nj b3BlJnF1b3Q7Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mcXVvdDthdWQmcXVvdDsgKGF1ZGllbmNlKSBzcGVjaWZpZXMgdGhlIHRhcmdl dCBjbGllbnQsIGJ1dCBub3QgdGhlIGludGVuZGVkIHVzYWdlIChhY2Nlc3MgdG9rZW4gdG8gYXV0 aG9yaXplIHJlc291cmNlIGFjY2VzcyBvciBTRVQgdG8gY29tbXVuaWNhdGUgYSBzZWN1cml0eSBl dmVudD8pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ JnF1b3Q7c2NvcGUmcXVvdDsgaXMgbm90IHVzZWQgYnkgU0VULjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9uJ3Qga25vdyB3aGF0IGRvIHlvdSBt ZWFuIGJ5ICZxdW90O2ludGVuZCZxdW90OyAob3IgaW50ZW50KT88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy Pg0KPGJyPg0KSGVuazxicj4NCjxicj4NCk9uIDA2LzEzLzIwMTcgMDE6MDEgQU0sIFJpY2hhcmQg QmFja21hbiwgQW5uYWJlbGxlIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzIGZvciBwdXR0aW5nIHRoaXMgdG9nZXRoZXIhPGJyPg0KPGJyPg0K SSB0aGluayB0aGUgYXNzdW1wdGlvbnMgaW5oZXJlbnQgaW4gMy45IGFyZSBmbGF3ZWQ6PGJyPg0K PGJyPg0KwrdXZSBjYW7igJl0IGd1YXJhbnRlZSB0aGF0IGV2ZXJ5IHR5cGUgb2YgSldUIHdpbGwg aGF2ZSBhIG11dHVhbGx5IGV4Y2x1c2l2ZSBzZXQgb2YgdmFsaWQgY2xhaW1zIGFuZC9vciBoZWFk ZXIgcGFyYW1ldGVycywgYW5kIGVuZm9yY2luZyB0aGlzIHJlcXVpcmVzIGEg4oCcZmFpbCBvbiBh biB1bnJlY29nbml6ZWQgY2xhaW3igJ0gYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgSldUcyBmcm9t IHNvbWUgZnV0dXJlIHNwZWMgY2Fu4oCZdCBiZSBtaXN0YWtlbiBmb3IgSldUcw0KIGZyb20gYSBj dXJyZW50IHNwZWMuPGJyPg0KPGJyPg0KwrdJdCBpcyB1bnJlYWxpc3RpYyB0byBleHBlY3QgaW1w bGVtZW50ZXJzIHRvIGFkaGVyZSB0byB0aGUg4oCcZGlmZmVyZW50IGtleXMgZm9yIGRpZmZlcmVu dCBraW5kcyBvZiBKV1Rz4oCdIHJ1bGUuIFdoZXRoZXIgbWFuZGF0ZWQgYnkgdGhlIHNwZWMgb3Ig bm90LCBpbXBsZW1lbnRlcnMgd2lsbCBpZ25vcmUgdGhpcyBiZWNhdXNlIG1hbmFnaW5nIG9uZSBr ZXkgaXMgZWFzaWVyIHRoYW4gbWFuYWdpbmcgTiBkaWZmZXJlbnQga2V5cy48YnI+DQo8YnI+DQrC t0RpdHRvIGZvciDigJxhdWTigJ0gYW5kIOKAnGlzc+KAnSBjbGFpbXMuPGJyPg0KPGJyPg0KJiM0 MzsxIGZvciBhIOKAnHR5cGXigJ0gb3Ig4oCcdXNhZ2XigJ0gY2xhaW0vaGVhZGVyIHBhcmFtZXRl ci48YnI+DQo8YnI+DQotLTxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3 Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48YnI+DQo8 YnI+DQpJZGVudGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KkZyb206ICpJZC1ldmVudCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNr LmhhcmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCipEYXRlOiAqTW9uZGF5LCBKdW5l IDEyLCAyMDE3IGF0IDM6MTggUE08YnI+DQoqVG86ICpNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBo cmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7 PGJyPg0KKkNjOiAqQWRhbSBEYXdlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYXdlc0Bnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWRhd2VzQGdv b2dsZS5jb208L3NwYW4+PC9hPiZndDssICZxdW90O21hdGFrZSwgbm92JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bm92QG1hdGFrZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPm5vdkBtYXRha2UuanA8L3NwYW4+PC9hPiZndDssIElEIEV2ZW50cyBNYWls aW5nDQogTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3Nw YW4+PC9hPiZndDssICZxdW90O1BoaWwgSHVudCAoSURNKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQoqU3Vi amVjdDogKlJlOiBbSWQtZXZlbnRdIHNvbHV0aW9uIGZvciBJZC9BY2Nlc3MgVG9rZW4gY29uZnVz aW9uIGFuZCBkaXN0aW5jdCBTRVQgaXNzdWVyPGJyPg0KPGJyPg0KQWdyZWVkLiBOb3RlIHRoYXQg dGhlcmUgaXMgc3RpbGwgbG90cyBvZiBkaXNjdXNzaW9uIG9uIHdoYXQgc2hvdWxkIGJlIGluIDMu OS48YnI+DQo8YnI+DQpPbiBNb24sIEp1biAxMiwgMjAxNyBhdCAzOjE1IFBNLCBNYXJpdXMgU2N1 cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86bXNjdXJ0ZXNjdUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bXNjdXJ0ZXNjdUBnb29nbGUuY29t PC9zcGFuPjwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tc2N1cnRlc2N1 QGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDsmZ3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyBUaGFua3MgZm9yIHRoZSBwb2ludGVyIERpY2ssIHZlcnkgZ29vZCB0aW1pbmcgOi0p PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgaXNzdWUgaXMgZGVzY3JpYmVkIGJ5ICZxdW90 OzIuNy4gQ3Jvc3MtSldUIENvbmZ1c2lvbiZxdW90OyBhbmQgdGhlPGJyPg0KJm5ic3A7ICZuYnNw OyBtaXRpZ2F0aW9uIGlzIGluICZxdW90OzMuOS4gVXNlIE11dHVhbGx5IEV4Y2x1c2l2ZSBWYWxp ZGF0aW9uIFJ1bGVzIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgRGlmZmVyZW50IEtpbmRzIG9mIEpX VHMmcXVvdDssIHNwZWNpZmljYWxseSAmcXVvdDtVc2UgZGlmZmVyZW50IHNldHMgb2Y8YnI+DQom bmJzcDsgJm5ic3A7IHJlcXVpcmVkIGNsYWltcy4uLiZxdW90OywgJnF1b3Q7VXNlIGRpZmZlcmVu dCBrZXlzIGZvciBkaWZmZXJlbnQga2luZHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7IEpXVHMuJnF1 b3Q7IGFuZCAmcXVvdDtVc2UgZGlmZmVyZW50IGlzc3VlcnMgZm9yIGRpZmZlcmVudCBraW5kcyBv ZiBKV1RzLiZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgc3RpbGwgdGhpbmsgdGhh dCBhICZxdW90O3R5cGUmcXVvdDsgY2xhaW0gd291bGQgYnJpbmcgYSBsb3Qgb2YgY2xhcml0eSBh bmQ8YnI+DQombmJzcDsgJm5ic3A7IHNhZmV0eS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IE1hcml1czxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgT24gVGh1LCBKdW4gOCwgMjAxNyBh dCA5OjU5IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaWNrLmhh cmR0QGdtYWlsLmNvbTwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7 Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFyb24s IE1pa2UgYW5kIEkganVzdCBwdWJsaXNoZWQgYW4gQkNQIElEIGZvciBKV1Q8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2 NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cC0zQV9fc2VsZi0yRGlzc3VlZC5pbmZvXy0zRnAtM0QxNjkwJmFtcDtk PUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209 VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1hN1h2WjVq VGJ0QTJ2amZhSElNYnZFT3BTQkJsQnBkc0RrSVRaTWNVSVVRJmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9w PTE2OTA8L3NwYW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBP biBUaHUsIEp1biA4LCAyMDE3IGF0IDk6MDIgUE0gQWRhbSBEYXdlcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkYXdlc0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+YWRhd2VzQGdvb2dsZS5jb208L3NwYW4+PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphZGF3ZXNAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmFkYXdlc0Bnb29n bGUuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHdhcyBpbml0aWFsbHkgYSBmYW4gb2Yga2Vl cGluZyBTRVRTIHRvIGJlIHZlcnkgc2ltaWxhciB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkIHRva2VucyBidXQgSSBub3cgdGhpbmsgdGhpcyBpcyBh IGJldHRlciBwbGFuLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IE9uIFRodSwgSnVuIDgsIDIwMTcgYXQgNjo1NiBQTSBtYXRha2UsIG5vdiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm5vdkBtYXRha2UuanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5ub3ZAbWF0YWtlLmpwPC9zcGFuPjwvYT48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpub3ZAbWF0YWtlLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+bm92QG1hdGFrZS5qcDwvc3Bhbj48L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz OzEgZXNwZWNpYWxseSBmb3IgJnF1b3Q7dHlwZSZxdW90Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjAxNy0wNi0wOSAx MDozMiBHTVQmIzQzOzA5OjAwIFBoaWwgSHVudCAoSURNKTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0 Ozo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzsxPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFBoaWw8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBPbiBKdW4gOCwg MjAxNywgYXQgNjoyOCBQTSwgTWFyaXVzIFNjdXJ0ZXNjdTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyZn dDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyBUaGVyZSB3ZXJlIGEgY291cGxlIG9mIHByb3Bvc2FscyBvbiBob3cgdG88YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZGlzdGluZ3Vpc2ggU0VUcyBmcm9tIElkIFRva2VucyBhbmQgQWNjZXNz IFRva2VucyBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdWNoIGEgd2F5IHRoYXQgbmFpdmUgaW1wbGVt ZW50YXRpb25zIHdpbGwgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbmZ1c2Ugb25lIGZvciB0aGUg b3RoZXIgYW5kIG9wZW4gdXAgc2VjdXJpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdnVsbmVyYWJpbGl0 aWVzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgVGhlcmUgaXMgYWxzbyBhbm90aGVyIGltcG9ydGFudCByZXF1aXJlbWVudDogdGhlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFNFVCBpc3N1ZXIgaW4gc29tZSBjYXNlcyBtdXN0IGJlIGRpZmZlcmVu dCBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzdWImcXVvdDsgaXNzdWVyLiBUaGlz IGlzIHRoZSBjYXNlIG9mIGFuIFJQIHNlbmRpbmcgU0VUczxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byBh biBJZFAuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyBXaXRoIHRoZXNlIHJlcXVpcmVtZW50cyBpbiBtaW5kIEkgcHJvcG9zZSB0aGU8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZm9sbG93aW5nOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IC0g Ym90aCAmcXVvdDtzdWImcXVvdDsgYW5kICZxdW90O2lzcyZxdW90OyB0byBiZSBkZWZpbmVkIGF0 IHRoZSBldmVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZXZlbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IC0gJnF1b3Q7aXNzJnF1b3Q7IGF0IGV2ZW50IGxldmVsIGFuZCBhdCB0b3AgU0VUIGxl dmVsIGNhbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyAtICZxdW90O2lzcyZxdW90OyBhbmQgJnF1b3Q7c3ViJnF1b3Q7IGF0IGV2ZW50 IGxldmVsIGNhbiBiZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWNyb3NzIGV2ZW50cyBp biB0aGUgc2FtZSBTRVQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAtICZxdW90O3N1YiZx dW90OyBzaG91bGQgTk9UIGJlIHByZXNlbnQgYXQgdGhlIHRvcCBTRVQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgbGV2ZWwgKHRoaXMgc29sdmVzIHRoZSBkaXNhbWJpZ3VhdGlvbiksIHBsZWFzZSBub3RlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZxdW90O3Nob3VsZCZxdW90OyBhbmQgbm90ICZxdW90O211c3QmcXVv dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IFRoaXMgc29sdXRpb24gYWxzbyBhbGxvd3MgZGlmZmVyZW50IHByb2ZpbGVzIHRoYXQ8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZGVmaW5lIGV2ZW50IHR5cGVzIHRvIGRlZmluZSBhZGRpdGlvbmFsIGNs YWltczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZWxhdGVkIHRvIHN1YiAobGlrZSBlbWFpbCBvciBwaG9u ZV9udW1iZXIpIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaW5jZSBhbGwgdGhlc2UgY2xhaW1zIHdp bGwgYmUgYXQgdGhlIGV2ZW50IGxldmVsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXJlIHdpbGwgYmUg bm8gY29sbGlzaW9ucyBvciBhbWJpZ3VpdHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBBbm90aGVyIHByb3Bvc2FsICh3aGljaCBJIHN1 cHBvcnRlZCkgd2FzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlZmluZSBhIGNvbXBvc2l0ZSAmcXVv dDthdWQmcXVvdDsgY2xhaW0uIFRoaXMgaXMgbm90IHNvbHZpbmc8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg dGhlIHJlcXVpcmVtZW50IGZvciBhIGRpc3RpbmN0Jm5ic3A7IFNFVCBpc3N1ZXIuIEFsc28sPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGhhdmluZyB0aGUgc2FtZSBjbGFpbSBuYW1lIGhhdmluZyBkaWZmZXJl bnQgc3ludGF4PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIGRpZmZlcmVudCB0b2tlbiB0eXBlcyBjb3Vs ZCBsZWFkIHRvIGNvbmZ1c2lvbi48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEFuZCB5ZXQgYW5vdGhlciBwcm9wb3NhbCB3YXMgdG8gaW50 cm9kdWNlIGEgbmV3PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNsYWltIGZvciBKV1RzIHRoYXQgZGVmaW5l cyBhICZxdW90O3R5cGUmcXVvdDsuIFRoaXMgaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByYWN0 aWNhbCBpbiB0aGUgc2hvcnQgdGVybSwgYW5kIGl0IGFsc28gaXMgbm90PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHNvbHZpbmcgdGhlIGRpc3RpbmN0IGlzc3VlciByZXF1aXJlbWVudCwgYnV0IEkgdGhpbms8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgdGhpcyBpcyBzb21ldGhpbmcgdGhlIEpXVCBncm91cCBzaG91bGQg c2VyaW91c2x5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNpZGVyLjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhvdWdodHM/PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBNYXJpdXM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IElkLWV2ZW50IG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PHNwYW4gY2xhc3M9Im04NDAxNzE2 NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQt ZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3 OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQt ZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1 Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPUptdXV0Qng0REFQcDc0QVVMY3gySV9qdmdYenVhNm1pUmlIcVdnZnhxbWcmYW1w O3M9NXhRcXZCaVhaNklqOU5HRHdWcVhvVnBuODhZS09DZDBteFBRRkpMaHhXSSZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1KbXV1dEJ4NERBUHA3NEFVTGN4MklfanZnWHp1YTZt aVJpSHFXZ2Z4cW1nJmFtcDtzPTV4UXF2QmlYWjZJajlOR0R3VnFYb1Zwbjg4WUtPQ2QwbXhQUUZK TGh4V0kmYW1wO2U9PC9zcGFuPjwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im04NDAx NzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEy OTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklkLWV2 ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBj bGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1 NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1R bDdqNzQ2WENzRGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0 RUtiOXV5ZzdvTVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1l dmVudDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNz PSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4 NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0ibTg0MDE3MTY1 MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNzPSJt ODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1 OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3R1U3SlBLSHNobVFsN2o3NDZY Q3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0ZaWVZJVFg5dWdMRDRFS2I5dXln N29NVTdUbUdNU1dXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9z cGFuPjwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAtLTxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1Njk3Mjk0MzY4NTM0 MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFkYW0g RGF3ZXMgfCBTci4gUHJvZHVjdCBNYW5hZ2VyIHw8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNA Z29vZ2xlLmNvbTwvc3Bhbj48L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hZGF3ZXNAZ29vZ2xl LmNvbTwvc3Bhbj48L2E+Jmd0OyB8PGEgaHJlZj0idGVsOiUyQjElMjA2NTAtMjE0LTI0MTAiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBjbGFzcz0iZ2MtY3MtbGluayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+JiM0MzsxIDY1MC0yMTQtMjQxMDwvc3Bhbj48L3NwYW4+PC9hPjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJ0ZWw6JTI4 NjUwJTI5JTIwMjE0LTI0MTAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj50ZWw6KDY1MCklMjAyMTQtMjQxMDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzEx Mjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBp ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2 OTcyOTQzNjg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBp ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9Im04NDAxNzE2NTI4MTMxMTI5ODc4bS02NjU2OTcyOTQz Njg1MzQyMTI1bS00NjI5ODQyNTY5Mzg1MTU5OTg4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21a dUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAtLTxzcGFuIGNsYXNzPSJtODQwMTcxNjUyODEzMTEyOTg3OG0tNjY1 Njk3Mjk0MzY4NTM0MjEyNW0tNDYyOTg0MjU2OTM4NTE1OTk4OGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJzY3Jp YmUgdG8gdGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUdhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdK UEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1pNzVVdzhhZWhZdmxwSVpO TDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9oYXJkdHdhcmUuY29tLzwvc3Bhbj48L2E+Jmd0 Ow0KIG1haWwgbGlzdCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFybiBh Ym91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS08 c3BhbiBjbGFzcz0ibTg0MDE3MTY1MjgxMzExMjk4NzhtLTY2NTY5NzI5NDM2ODUzNDIxMjVtLTQ2 Mjk4NDI1NjkzODUxNTk5ODhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+ DQo8YnI+DQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21f JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm YW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1p NzVVdzhhZWhZdmxwSVpOTDdOeHFHeGhoMVRPclFPVVgyWE1ZQmVyVjgwJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHA6Ly9oYXJkdHdhcmUuY29t Lzwvc3Bhbj48L2E+Jmd0Ow0KIG1haWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFt IHdvcmtpbmcgb24hPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdh USZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDty PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdH VTdKUEtIc2htUWw3ajc0NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZ VklUWDl1Z0xENEVLYjl1eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1Vc2xqN0dVN0pQS0hzaG1RbDdqNzQ2WENz RGZ0LTAwWV8zelJvYWkxMTVjJmFtcDtzPVA3bVp1R3pzc0tGWllWSVRYOXVnTEQ0RUtiOXV5Zzdv TVU3VG1HTVNXV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklk LWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209VXNsajdHVTdKUEtIc2htUWw3ajc0 NlhDc0RmdC0wMFlfM3pSb2FpMTE1YyZhbXA7cz1QN21adUd6c3NLRlpZVklUWDl1Z0xENEVLYjl1 eWc3b01VN1RtR01TV1dzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lD QWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVVzbGo3 R1U3SlBLSHNobVFsN2o3NDZYQ3NEZnQtMDBZXzN6Um9haTExNWMmYW1wO3M9UDdtWnVHenNzS0Za WVZJVFg5dWdMRDRFS2I5dXlnN29NVTdUbUdNU1dXcyZhbXA7ZT08L3NwYW4+PC9hPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUdhUSZh bXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpC bTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209bC1PODJOTEkt YjhRRGwyUTlUa3BWb2JRejNoXzRUeUJHQXE1cGZac09jdyZhbXA7cz0wTFdSbEdUSXFpVHNEaG1I dVJJQjUtUlJmdDgyQzcyOS1QRVlKaEx1NVNRJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3Vu ZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVw ZWF0OmluaXRpYWwgaW5pdGlhbCI+SWQtZXZlbnQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0 aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48YSBocmVmPSJt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFs IGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1sLU84Mk5MSS1iOFFEbDJROVRr cFZvYlF6M2hfNFR5QkdBcTVwZlpzT2N3JmFtcDtzPTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0 ODJDNzI5LVBFWUpoTHU1U1EmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVu dDwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9z cGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZhbXA7bT1sLU84Mk5MSS1iOFFEbDJROVRrcFZvYlF6M2hfNFR5QkdBcTVwZlpzT2N3JmFtcDtz PTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0ODJDNzI5LVBFWUpoTHU1U1EmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdNR2FRJmFtcDtjPVJvUDFZdW1D WENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBG a0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1sLU84Mk5MSS1iOFFEbDJROVRrcFZv YlF6M2hfNFR5QkdBcTVwZlpzT2N3JmFtcDtzPTBMV1JsR1RJcWlUc0RobUh1UklCNS1SUmZ0ODJD NzI5LVBFWUpoTHU1U1EmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwv c3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY4PR21MB050497B3B24664BCC467D8E2F5DF0CY4PR21MB0504namp_-- From nobody Mon Jun 26 12:32:42 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D34126B71 for ; Mon, 26 Jun 2017 12:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKrZ15NEwMMB for ; Mon, 26 Jun 2017 12:32:34 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392EA124D37 for ; Mon, 26 Jun 2017 12:32:34 -0700 (PDT) X-AuditID: 12074424-9c3ff70000001d32-23-595161502751 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 17.E0.07474.05161595; Mon, 26 Jun 2017 15:32:32 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v5QJWU7s010617; Mon, 26 Jun 2017 15:32:31 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5QJWQBf032166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2017 15:32:27 -0400 From: Justin Richer Message-Id: <45A70706-67C2-41B4-9AB4-A3F23E8C910C@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_25A110D7-5E24-4523-BFE5-2BB04161A6EC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Jun 2017 15:32:25 -0400 In-Reply-To: Cc: Marius Scurtescu , Phil Hunt , "Richard Backman, Annabelle" , John Bradley , Henk Birkholz , Yaron Sheffer , ID Events Mailing List To: Mike Jones References: <0A8214E9-5FF7-4898-9D3C-F518A9A31DC2@amazon.com> <3202DFD2-5156-41C4-AC05-94F9BDCDADB1@oracle.com> <1629046b-2447-aef6-8f2e-2333fb1f3ee3@gmail.com> <6A2C250A-D2E3-4868-950F-DFAFBDF3C394@ve7jtb.com> <1915CB57-66AE-4C8B-AD1E-24123E9BE3FA@ve7jtb.com> <80510456-2187-401D-8BF9-8E3118435B3C@oracle.com> <370B5025-BD04-4B05-9FFD-D8850230BBBF@amazon.com> <00C1EE28-F966-4C29-A5D1-DD54C103FF0D@oracle.com> <6d9e7ad9-8096-09e9-1759-2ae0f9481a83@mit.edu> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsUixG6nohuQGBhpcPK9pUXDv7+sFh0Lupks 9k77xGJx6+waJosF8xvZLdofc1isvvuXzWLV/RnsDhweKy50sXrsnHWX3WPBplKPJUt+Mnm0 7vjL7vHx6S0Wj44HNxg9bt/eyBLAEcVlk5Kak1mWWqRvl8CVceDiC8aCu9O5KyYCLWpg/PGM s4uRk0NCwERiyrwDLF2MXBxCAouZJKZ/fcYI4WxklHg27ww7SJWQwEMmiV/n4kBsNgFVielr WphAbF4BK4k7U9oYQWxmgSSJtjtbWLsYOYDi+hK9z8HCwgIREv+39bGAhFmAWt938oOYnAKx EuvbtEA2MQtcZZI492MOM0i5iICOxOOL39ggtl7klOhaWwZxp6zErdmXmCcw8s9CsmwWwjKI sLbEsoWvmSFsTYn93ctZMMU1JDq/TWRdwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzez RC81pXQTIziWXFR2MHb3eB9iFOBgVOLh/cEUGCnEmlhWXJl7iFGSg0lJlHdVOFCILyk/pTIj sTgjvqg0J7X4EKMEB7OSCG8wN1CONyWxsiq1KB8mJc3BoiTOK67RGCEkkJ5YkpqdmlqQWgST leHgUJLgZU8AahQsSk1PrUjLzClBSDNxcIIM5wEa7gZSw1tckJhbnJkOkT/FqCglzssPkhAA SWSU5sH1glJdwtvDpq8YxYFeEeZ1AqniAaZJuO5XQIOZgAazzAsAGVySiJCSamA8Ws5cNGV+ 5M5uHr7Hl9y+d1nP0oj/Xu92/ua/ki88fWscevjO+6utM0iL5tlpprZ5j+OdPKtetYuVXaVm AmYf3sVsY9q/ReT7JTNpx8S9PkuVApqb4++qNi50OcnFF1U7cRez4fZNzw4Vlhw8b+Ry0N3x 0VzVLx/m9bkvNGSWsvi+ODvozx4lluKMREMt5qLiRAA9s14tUAMAAA== Archived-At: Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:32:40 -0000 --Apple-Mail=_25A110D7-5E24-4523-BFE5-2BB04161A6EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, I disagree with that assessment and think you=E2=80=99re drawing a false = equivalence. SET *should* be limited to a semantically related set of = items. Otherwise, what=E2=80=99s the point of a standard? It would just = be =E2=80=9Coh just everyone use JWTs for different things=E2=80=9D.=20 It sounds like what you want from this group is to declare an = =E2=80=9Cevent=E2=80=9D top-level claim and then get out of the way. I = don=E2=80=99t think that=E2=80=99s useful on its own, nor is it the best = we can do.=20 I think the rules I laid out are applicable to all of the use cases that = have been brought up here so far. RISC isn=E2=80=99t the right place to = have this discussion =E2=80=94 this list is. =E2=80=94 Justin > On Jun 26, 2017, at 1:05 PM, Mike Jones = wrote: >=20 > Justin, > =20 > The rules you=E2=80=99re proposing may be fine for a SET profile for a = particular kind of application. I encourage you to join the RISC = working group and work on them there. But they would limit the use = cases that SETs could be used for, which would be unfortunate and = unnecessary. > =20 > An analogy with JWT is illustrative. JWT is intentionally = general-purpose, leaving it up to application profiles what claims to = use and what their semantics are. This enables JWTs to be used for ID = Tokens = and also for completely unrelated uses, such as SIP = and Caller ID = . There is no = expectation of interoperability between these different JWT = applications. Indeed =E2=80=93 both the syntax *and the semantics*, = such has how to determine what keys are valid, are different. It=E2=80=99= s this flexibility that makes JWTs general-purpose. > =20 > Likewise, SET as currently specified is similarly general-purpose. = Application profiles define what SET claims to use and their semantics. = There is no expectation of interoperability between different SET = profiles, nor should there be, as their applications are different. = Trying to make SETs require choices appropriate to a particular profile = will necessarily make them a poor or impossible fit for others. This = would be a very bad thing. > =20 > Ironically, =E2=80=9Clocking down=E2=80=9D SET to require choices = motivated by a particular profile wouldn=E2=80=99t help that profile at = all, as it would work the same whether SET was =E2=80=9Clocked down=E2=80=9D= or not. But it would unnecessarily preclude use of SETs in other = contexts that they are currently a great fit for. > =20 > -- = Mike > =20 > From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 > Sent: Monday, June 26, 2017 9:43 AM > To: Justin Richer > Cc: Mike Jones ; Phil Hunt = ; Richard Backman, Annabelle = ; John Bradley ; Henk Birkholz = ; Yaron Sheffer = ; ID Events Mailing List > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Justin, in the case when an RP is issuing the SET to send it to an = IdP, a top level sub as you describe it may not be possible. Or maybe I = misunderstand. > =20 > We agree on "iss" I think, in this case it points to the RP. A top = level "sub" though is problematic, The RP in many cases has the opaque = "sub" as issued by the IdP, but this value is globally unique only when = combined with the IdP "iss". > =20 > Not sure why event.aud would be necessary? >=20 > Marius > =20 > On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer > wrote: > Mike, this is not at all what I see for having the "most support". = Instead I'm seeing a lot of call for having "sub" defined clearly in the = event payload only. >=20 > The "sub" of the main body is the subject as known by the issuer of = the SET itself. This might be the same subject that the subject is known = by at the target of the SET. There are many cases where this isn't true, = and so far one exception case where it is, sometimes. We should not be = writing this for the exception. >=20 > But I think there's a pretty clear path forward. The "sub" in the body = of a SET, if it is included, is *ALWAYS* in the context of the "iss" of = the SET. Always, full stop, no exceptions. No global namespaces, no = restrictions on content, no formats -- it's an opaque (to the SET = standard) value in the domain of the issuer of the SET.=20 >=20 > Event payloads, defined in profiles, describe a subject of the event = itself. Importantly, this is the subject as known by the context in = which the event will be *received*, not in which it was *issued*. = Sometimes those are the same, more often (as we're seeing) we can't = guarantee that. We should not depend on that and we should not treat the = exceptional case as the usual, no matter what syntax another group has = come up with. >=20 > So here's the thing. I think the "sub" of an event should be optional, = and ALWAYS in the context of the issuer, and profiles should not places = further constraints on that. Events themselves should be self-contained. = I regret that we didn't make the registration object in RFC7591 more = self-contained, as that's caused implementation and extension issues. I = think events should always have an internal subject/issuer pair, in the = context of where the event is being consumed. We need to define what = iss/sub mean (in a grand sense) inside the event object in this = document, so that different events don't reinvent the same thing over = and over. If a profile wants to leave that out because they don't need = an identifier for the payload, then they can leave it out. If they want = to leave it out because they want to assume there will "always" be an = iss/sub in the root of the SET, then I have a problem with that. The = issuer of the SET can, and probably does, have its own identifier which = can't be assumed to be universal. Proposing a global subject namespace = or format, as has been suggested elsewhere on this list, is ludicrous = and will never fly as it goes against how JWT namespacing for people and = objects has always worked. We should have a clear semantic data = structure that can be extended and used by all of the use cases that = we've adopted. Optimizing at this stage, especially based on one event, = is going to just lead to things being broken and back-patched later on. = But if one spec wants to leave out the iss/sub inside the event? They = can still do that, but I think that's pretty daft. >=20 > =20 >=20 > In summary: >=20 > iss: issuer of the event > sub: subject of the event as known by the issuer of the event > event.sub: subject of the event as known by the recipient of the event > event.iss: context for the subject of the event as known by the = recipient of the event > event.aud: recipient of the event > =20 >=20 > -- Justin >=20 > =20 > On 6/21/2017 7:45 PM, Mike Jones wrote: > The proposal that I believe has the most support is keeping things as = they are, leaving it up to profiles and applications to define which = claims they use and how they use them. > =20 > It would be fine for some profiles to use the language below. > =20 > =E2=80=93 Mike > From: Phil Hunt > Sent: Wednesday, June 21, 2017 6:39 PM > To: Richard Backman, Annabelle > Cc: Marius Scurtescu ; John Bradley = ; Henk Birkholz = ; Justin Richer = ; Yaron Sheffer ; = Mike Jones ; ID Events Mailing List = > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > So I understand what is being proposed is: > =20 > If the event type uses =E2=80=9Csub=E2=80=9D to identify its subject, = and the issuer of the subject is identical to the issuer for the event, = then =E2=80=9Csub=E2=80=9D may be used at the top level. Otherwise, the = subject of an event (e.g. =E2=80=9Csub=E2=80=9D) and any other claims = required to uniquely identify the subject MUST be contained in the event = payload. > =20 > For example, an ip address of 1.2.3.4 might be represented in a = =E2=80=9Cipaddress=E2=80=9D claim defined in the event payload. = =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4" > A SCIM resource URI of = https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 = might = be identified in the event payload as: = =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a24= 2bd3859c82c4 = =E2=80=9D= > =20 > A Connect Logout event from an OP uses the top level sub claim and = depends on =E2=80=9Ciss=E2=80=9D being the same for the event issuer AND = the subject. This means that no party may issue logout events on behalf = of the OP. > =20 > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle = > wrote: > =20 > Fair point. If we do not intend to support multiple profiles within a = single SET, then I=E2=80=99m less concerned about leaving sub semantics = up to the profiles. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Marius Scurtescu > > Date: Wednesday, June 21, 2017 at 2:58 PM > To: "Richard Backman, Annabelle" > > Cc: "Phil Hunt (IDM)" >, John Bradley >, Henk Birkholz = >, Justin Richer = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Example for multiple events within same profile: IdP account is = disabled (because of hijacking), this can lead to two events: > 1. "account-disabled" > 2. "sessions-revoked" >=20 > Marius > =20 > On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle = > wrote: > The spec says that the events claim SHOULD NOT be used to express = multiple logical events. If it=E2=80=99s also not used to express events = from different profiles that correspond to the same logical event (e.g. = an OIDC backchannel logout event alongside a hypothetical RISC logout = event), then I=E2=80=99m not sure what use case that leaves for multiple = events in one SET. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event > on behalf of "Phil Hunt (IDM)" = > > Date: Wednesday, June 21, 2017 at 2:12 PM > To: John Bradley > > Cc: "Richard Backman, Annabelle" >, Henk Birkholz = >, Justin Richer = >, Marius Scurtescu = >, Yaron Sheffer = >, Michael Jones = >, ID = Events Mailing List > >=20 > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Separate or combined may be evolving. Mike wants to keep the current = backchannel logout very narrowly scoped. He suggested risc define its = own duplicate definitions and meanings.=20 > =20 > That leads me to believe we will have multi-type events in practice. > =20 > Session cancellation can occur for many reasons. One of the = differentiators we had tried to make was an assumption that user = initiated events would be part of connect. Risk would cover variations = that drive off of risk calculations like password reset.=20 > =20 > There are also signout events at rp's to let the OP know. These are = not commands but notification that a resource session is cancelled. IOW = single sign out not expected.=20 >=20 > Phil >=20 > On Jun 21, 2017, at 1:58 PM, John Bradley > wrote: >=20 > I thought we decided that we are only allowing set messages form the = same family that agree on top level claims. > =20 > Otherwise there can be no top level claims and we are really defining = a alternative format to JWT in some ways. > =20 > John B. > =20 > On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle = > wrote: > =20 > I agree with John that the JWT type confusion problem and the SET sub = problem can and should be discussed separately. The secevents WG is = probably not the right setting to discuss the former. > =20 > My concern with the sub claim is that two profiles may dictate = conflicting semantics (e.g. Profile A says it=E2=80=99s a phone number, = Profile B says it=E2=80=99s an email address). If these profiles don=E2=80= =99t provide an alternate way to declare subject of their events, then = they cannot be present within the same token. This incompatibility trap = seems like something that could be easily missed by groups profiling = SET. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: John Bradley > > Date: Wednesday, June 21, 2017 at 1:39 PM > To: Yaron Sheffer > > Cc: Justin Richer >, Marius = Scurtescu >, = Annabelle Richard >, = Phil Hunt >, Michael = Jones >, ID Events Mailing List = >, Henk Birkholz = > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > In the envelope typ is a media/mime type. Registering = application/idt+jwt if we register jwt as a structured name sufix. =20 > =20 > Using the cty is also possible. I need to think about what is better = but we can agree on a convention. > =20 > Not everything is going to be a set token like not every JWS is a JWT. > =20 > If we are going to define processing rules to stop collisions and = confusion around JWT for different purposes, we should just start using = the typ parameter based on the existing spec. > =20 > In general content sniffing if there is more than one option = eventually gets you into trouble. > =20 > I am not convinced that forcing there to be no sub at the top level is = a good idea. =20 > =20 > It is not the way we should differentiate between SET and id_tokens. > =20 > If sub is not allowed at the top level people will do non SET JWT for = things where the subject is scoped to the iss of the token. > =20 > I think defining sub to be part of the event for cases where the sub = is scoped differently from the issuer of the token is fine, but should = not be required for all event types. > =20 > I think we should solve the confusion issue separately from the sub = issue. > =20 > Sorry I am at CIS so trying to catch up on lists. > =20 > John B. > =20 > On Jun 17, 2017, at 3:45 PM, Yaron Sheffer > wrote: > =20 > So to summarize what I'm seeing on this thread: > Everybody agrees with Marius's short-term solution, specific rules for = "sub" and "iss" that can be defined in the SET spec. > Almost everybody agrees on a long-term "usage" claim ("type" is taken) = that should be defined elsewhere, e.g. in the JWT BCP. > Did I miss anything? > By the way, if we do add a "usage" claim, we need to also use it in = the SET document before it is published. > Thanks, > Yaron > =20 > On 15/06/17 22:08, Justin Richer wrote: > +1 to this as well.=20 > =20 > =E2=80=94 Justin > =20 > On Jun 15, 2017, at 1:09 PM, Marius Scurtescu > wrote: > =20 > +1 to what Annabelle said.=20 > =20 > Also, Mike you are missing the other requirement, for RPs to send = events to an IdP. The iss+sub pair at the top level is broken in this = case. >=20 > Marius > =20 > On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > +1 > =20 > Phil > =20 > On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle = > wrote: > Mike, > =20 > Your explanation for why this is a non-problem is dependent upon side = effects of elements of OpenID Connect that were not designed to solve = this issue. As a result, I see several issues with it: > 1. The caller of the Token Endpoint is the only party that can = be certain that a nonce-less ID Token is really an ID Token. Any party = that the caller passes the ID Token off to has no way to verify its = provenance. >=20 > 2. Any future ID Token distribution method needs to solve this = problem again. >=20 > 3. No other profile of JWT can ever use the "nonce=E2=80=9D = claim. >=20 > 4. This is only a solution for ID Tokens. Every other JWT profile = that cares about disambiguation has to invent its own solution to the = problem. >=20 > =20 > We know from experience that naming collisions and replay attacks are = both things that happen. What=E2=80=99s being proposed is a simple, = defensive measure against these risks. You brought up JWT libraries: a = general solution actually makes it easier to use common libraries for = JWT parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event > on behalf of Mike Jones = > > Date: Wednesday, June 14, 2017 at 1:16 PM > To: Marius Scurtescu > > Cc: "Richard Backman, Annabelle" >, ID Events Mailing List >, Henk Birkholz = > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > You=E2=80=99ve heard of =E2=80=9Cpremature optimization=E2=80=9D. = I=E2=80=99d characterize the proposals in this thread as =E2=80=9Cprematur= e pessimation=E2=80=9D =E2=80=93 making things that can and should be = simple complex, without data showing there=E2=80=99s any need to do so. > =20 > Mandatory solutions are being proposed in this thread to problems that = there=E2=80=99s no evidence that we actually even have. It=E2=80=99s = already been established that it=E2=80=99s impossible for a SET to be = confused for an ID Token =E2=80=93 see = https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html = . If people have data showing that this = is possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part. > =20 > The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting the use = of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type claim, = would make previously simple things unnecessarily complex. Yes, then = the result is then different than a normal JWT but a consequence of this = is that custom parsing code would have to be used, rather than a = standard JWT parser. The more unwieldy we make it to use SETs, the more = likely developers are to just create their own data structures. Keeping = it simple is the key to adoption. Standards are only useful if they are = actually used. > =20 > -- Mike > =20 > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Richard Backman, = Annabelle > Sent: Tuesday, June 13, 2017 5:33 PM > To: Marius Scurtescu >; Henk Birkholz = > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > Echoing Marius=E2=80=99s question: can you explain what you mean by = =E2=80=9Cintend=E2=80=9D? > =20 > To your first question, I think a better analogy would be the X.509 = Key Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context. > =20 > --=20 > Annabelle Richard Backman > Identity Services > =20 > =20 > From: Id-event > on behalf of Marius Scurtescu = > > Date: Tuesday, June 13, 2017 at 11:05 AM > To: Henk Birkholz > > Cc: ID Events Mailing List > > Subject: Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer > =20 > On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz = > wrote: > And a 2nd question. >=20 > What semantics would "usage" provide that that are not covered via = "intend", "audience", and "scope"? > =20 > "aud" (audience) specifies the target client, but not the intended = usage (access token to authorize resource access or SET to communicate a = security event?) > =20 > "scope" is not used by SET. > =20 > I don't know what do you mean by "intend" (or intent)? > =20 > =20 >=20 >=20 > Henk >=20 > On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote: > Thanks for putting this together! >=20 > I think the assumptions inherent in 3.9 are flawed: >=20 > =C2=B7We can=E2=80=99t guarantee that every type of JWT will have a = mutually exclusive set of valid claims and/or header parameters, and = enforcing this requires a =E2=80=9Cfail on an unrecognized claim=E2=80=9D = approach to ensure that JWTs from some future spec can=E2=80=99t be = mistaken for JWTs from a current spec. >=20 > =C2=B7It is unrealistic to expect implementers to adhere to the = =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80=9D rule. = Whether mandated by the spec or not, implementers will ignore this = because managing one key is easier than managing N different keys. >=20 > =C2=B7Ditto for =E2=80=9Caud=E2=80=9D and =E2=80=9Ciss=E2=80=9D = claims. >=20 > +1 for a =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D = claim/header parameter. >=20 > --=20 >=20 > Annabelle Richard Backman >=20 > Identity Services >=20 > *From: *Id-event > on behalf of Dick Hardt = > > *Date: *Monday, June 12, 2017 at 3:18 PM > *To: *Marius Scurtescu > > *Cc: *Adam Dawes >, = "matake, nov" >, ID Events Mailing = List >, "Phil Hunt (IDM)" = > > *Subject: *Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer >=20 > Agreed. Note that there is still lots of discussion on what should be = in 3.9. >=20 > On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu = >> wrote: >=20 > Thanks for the pointer Dick, very good timing :-) >=20 > The issue is described by "2.7. Cross-JWT Confusion" and the > mitigation is in "3.9. Use Mutually Exclusive Validation Rules for > Different Kinds of JWTs", specifically "Use different sets of > required claims...", "Use different keys for different kinds of > JWTs." and "Use different issuers for different kinds of JWTs.". >=20 > I still think that a "type" claim would bring a lot of clarity and > safety. >=20 >=20 > Marius >=20 > On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt > >> = wrote: >=20 > Yaron, Mike and I just published an BCP ID for JWT > http://self-issued.info/?p=3D1690 = >=20 > On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes > >> wrote: >=20 > I was initially a fan of keeping SETS to be very similar = to > id tokens but I now think this is a better plan. >=20 > On Thu, Jun 8, 2017 at 6:56 PM matake, nov > >> wrote: >=20 > +1 especially for "type" >=20 > 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) > >>: >=20 > +1 >=20 > Phil >=20 >=20 > > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu > > >> wrote: > > > > There were a couple of proposals on how to > distinguish SETs from Id Tokens and Access Tokens = in > such a way that naive implementations will not > confuse one for the other and open up security > vulnerabilities. > > > > There is also another important requirement: = the > SET issuer in some cases must be different from = the > "sub" issuer. This is the case of an RP sending = SETs > to an IdP. > > > > With these requirements in mind I propose the > following: > > - both "sub" and "iss" to be defined at the = event > level > > - "iss" at event level and at top SET level can > be different > > - "iss" and "sub" at event level can be = different > across events in the same SET > > - "sub" should NOT be present at the top SET > level (this solves the disambiguation), please = note > "should" and not "must" > > > > This solution also allows different profiles = that > define event types to define additional claims > related to sub (like email or phone_number) and > since all these claims will be at the event level > there will be no collisions or ambiguity. > > > > Another proposal (which I supported) was to > define a composite "aud" claim. This is not = solving > the requirement for a distinct SET issuer. Also, > having the same claim name having different syntax > in different token types could lead to confusion. > > > > And yet another proposal was to introduce a new > claim for JWTs that defines a "type". This is not > practical in the short term, and it also is not > solving the distinct issuer requirement, but I = think > this is something the JWT group should seriously > consider. > > > > Thoughts? > > > > Marius >=20 > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org = > > > > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DJmuutBx4DAPp74A= ULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhx= WI&e=3D = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Adam Dawes | Sr. Product Manager |adawes@google.com = > > |+1 = 650-214-2410 > > >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org = > > https://www.ietf.org/mailman/listinfo/id-event = >=20 > --=20 > Subscribe to the HARDTWARE > mail list to > learn about projects I am working on! >=20 >=20 >=20 > --=20 >=20 > Subscribe to the HARDTWARE > mail list to = learn about projects I am working on! >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DUslj7GU7JPKHshm= Ql7j746XCsDft-00Y_3zRoai115c&s=3DP7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSW= Ws&e=3D = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 >=20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_25A110D7-5E24-4523-BFE5-2BB04161A6EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike,

I = disagree with that assessment and think you=E2=80=99re drawing a false = equivalence. SET *should* be limited to a semantically related set of = items. Otherwise, what=E2=80=99s the point of a standard? It would just = be =E2=80=9Coh just everyone use JWTs for different = things=E2=80=9D. 

It sounds like what you want from this group is to declare an = =E2=80=9Cevent=E2=80=9D top-level claim and then get out of the way. I = don=E2=80=99t think that=E2=80=99s useful on its own, nor is it the best = we can do. 

I think the rules I laid out are applicable to all of the use = cases that have been brought up here so far. RISC isn=E2=80=99t the = right place to have this discussion =E2=80=94 this list is.

 =E2=80=94 = Justin
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

On Jun 26, 2017, at 1:05 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Justin,
 
The rules = you=E2=80=99re proposing may be fine for a SET profile for a particular = kind of application.  I encourage you to join the RISC working = group and work on them there.  But they would limit the use cases = that SETs could be used for, which would be unfortunate and = unnecessary.
 
An analogy = with JWT is illustrative.  JWT is intentionally general-purpose, = leaving it up to application profiles what claims to use and what their = semantics are.  This enables JWTs to be used for ID = Tokens and also = for completely unrelated uses, such as SIP and Caller = ID.  There is no expectation of interoperability between these = different JWT applications.  Indeed =E2=80=93 both the syntax *and the semantics*, such has how to determine what keys = are valid, are different.  It=E2=80=99s this flexibility that makes = JWTs general-purpose.
 
Likewise, = SET as currently specified is similarly general-purpose.  = Application profiles define what SET claims to use and their = semantics.  There is no expectation of interoperability between different = SET profiles, nor should there be, as their applications are = different.  Trying to make SETs require choices appropriate to a = particular profile will necessarily make them a poor or impossible fit = for others.  This would be a very bad thing.
 
Ironically, = =E2=80=9Clocking down=E2=80=9D SET to require choices motivated by a = particular profile wouldn=E2=80=99t help that profile at all, as it = would work the same whether SET was =E2=80=9Clocked down=E2=80=9D or = not.  But it would unnecessarily preclude use of SETs in other = contexts that they are currently a great fit for.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Marius Scurtescu [mailto:mscurtescu@google.com] 
Sent: Monday, June 26, 2017 9:43 = AM
To: Justin Richer <jricher@mit.edu>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt <phil.hunt@oracle.com>; Richard Backman, Annabelle = <richanna@amazon.com>; John Bradley <ve7jtb@ve7jtb.com>; = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Yaron Sheffer <yaronf.ietf@gmail.com>; ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] solution for = Id/Access Token confusion and distinct SET issuer
 
Justin, in the case when an RP is issuing the SET to send it = to an IdP, a top level sub as you describe it may not be possible. Or = maybe I misunderstand.
 
We agree on "iss" I think, in this case it points to the RP. = A top level "sub" though is problematic, The RP in many cases has the = opaque "sub" as issued by the IdP, but this value is globally unique = only when combined with the IdP "iss".
 
Not sure why event.aud would be = necessary?

Marius
 
On Sun, Jun 25, 2017 at 7:31 AM, Justin = Richer <jricher@mit.edu> wrote:

Mike, this is not at all what I = see for having the "most support". Instead I'm seeing a lot of call for = having "sub" defined clearly in the event payload only.

The "sub" of the main body is the = subject as known by the issuer of the SET itself. This might be the same = subject that the subject is known by at the target of the SET. There are = many cases where this isn't true, and so far one exception case where it = is, sometimes. We should not be writing this for the exception.

But I think there's a pretty clear = path forward. The "sub" in the body of a SET, if it is included, is = *ALWAYS* in the context of the "iss" of the SET. Always, full stop, no = exceptions. No global namespaces, no restrictions on content, no formats = -- it's an opaque (to the SET standard) value in the domain of the = issuer of the SET. 

Event payloads, defined in profiles, = describe a subject of the event itself. Importantly, this is the subject = as known by the context in which the event will be *received*, not in = which it was *issued*. Sometimes those are the same, more often (as = we're seeing) we can't guarantee that. We should not depend on that and = we should not treat the exceptional case as the usual, no matter what = syntax another group has come up with.

So here's the thing. I think the "sub" of an event should be = optional, and ALWAYS in the context of the issuer, and profiles should = not places further constraints on that. Events themselves should be = self-contained. I regret that we didn't make the registration object in = RFC7591 more self-contained, as that's caused implementation and = extension issues. I think events should always have an internal = subject/issuer pair, in the context of where the event is being = consumed. We need to define what iss/sub mean (in a grand sense) inside = the event object in this document, so that different events don't = reinvent the same thing over and over. If a profile wants to leave that = out because they don't need an identifier for the payload, then they can = leave it out. If they want to leave it out because they want to assume = there will "always" be an iss/sub in the root of the SET, then I have a = problem with that. The issuer of the SET can, and probably does, have = its own identifier which can't be assumed to be universal. Proposing a = global subject namespace or format, as has been suggested elsewhere on = this list, is ludicrous and will never fly as it goes against how JWT = namespacing for people and objects has always worked. We should have a = clear semantic data structure that can be extended and used by all of = the use cases that we've adopted. Optimizing at this stage, especially = based on one event, is going to just lead to things being broken and = back-patched later on. But if one spec wants to leave out the iss/sub = inside the event? They can still do that, but I think that's pretty = daft.

 

In summary:

  • iss: issuer of the = event
  • sub: subject of the event as known by the issuer of the = event
  • event.sub: subject of the event as known by the recipient = of the event
  • event.iss: context for the subject of the event as = known by the recipient of the event
  • event.aud: recipient of the event

 

 -- Justin

 
On 6/21/2017 7:45 PM, Mike Jones wrote:
The proposal that I believe has the most support is keeping = things as they are, leaving it up to profiles and applications to define = which claims they use and how they use them.
 
It would = be fine for some profiles to use the language below.
 
=E2=80=93 = Mike
From: Phil Hunt
Sent: Wednesday, June 21, = 2017 6:39 PM
To: Richard Backman, = Annabelle
Cc: Marius = Scurtescu; John Bradley; Henk = Birkholz; Justin Richer; Yaron Sheffer; Mike = Jones; ID Events Mailing = List
Subject: Re: [Id-event] solution = for Id/Access Token confusion and distinct SET issuer
 
So I understand what is being proposed = is:
 
If the event type uses =E2=80=9Csub=E2=80=9D to = identify its subject, and the issuer of the subject is identical to the = issuer for the event, then =E2=80=9Csub=E2=80=9D may be used at the top = level. Otherwise, the subject of an event (e.g. =E2=80=9Csub=E2=80=9D) = and any other claims required to uniquely identify the subject MUST be = contained in the event payload.
 
For example, an ip address of 1.2.3.4 = might be represented in a =E2=80=9Cipaddress=E2=80=9D claim defined in = the event payload. =E2=80=9Cipaddress=E2=80=9D:=E2=80=9D1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4=  might be = identified in the event payload as: =E2=80=9Csub=E2=80=9D:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4= =E2=80=9D
 
A Connect Logout event from an OP uses the top level sub = claim and depends on =E2=80=9Ciss=E2=80=9D being the same for the event = issuer AND the subject. This means that no party may issue logout events = on behalf of the OP.
 
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect & = Standards
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Jun 21, 2017, at 3:38 = PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
 
Fair point. If we do not intend to support multiple profiles = within a single SET, then I=E2=80=99m less concerned about leaving sub = semantics up to the profiles.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From: <= /b>Marius Scurtescu <mscurtescu@google.com>
Date: Wedn= esday, June 21, 2017 at 2:58 PM
To: "Ric= hard Backman, Annabelle" <richanna@amazon.com>
Cc: "Phi= l Hunt (IDM)" <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>,= Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer <jricher@mit.edu>, = Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing List = <id-event@ietf.org>
Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Example for multiple events within same = profile: IdP account is disabled (because of hijacking), this can lead = to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius
 
On Wed, Jun 21, 2017 at 2:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
The spec says = that the events claim SHOULD NOT be used to express multiple logical = events. If it=E2=80=99s also not used to express events from different = profiles that correspond to the same logical event (e.g. an OIDC = backchannel logout event alongside a hypothetical RISC logout event), = then I=E2=80=99m not sure what use case that leaves for multiple events = in one SET.
 
-- 
Annabelle Richard = Backman
Identity Services
 
 
From: <= /b>Id-event <id-event-bounces@ietf.org> on behalf of "Phil = Hunt (IDM)" <phil.hunt@oracle.com>Date: Wedn= esday, June 21, 2017 at 2:12 PM
To: John= Bradley <ve7jtb@ve7jtb.com>
Cc: "Ric= hard Backman, Annabelle" <richanna@amazon.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Justin Richer = <jricher@mit.edu>, Marius Scurtescu = <mscurtescu@google.com>, = Yaron Sheffer <yaronf.ietf@gmail.com>, Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing = List <id-event@ietf.org>

Subject: Re: = [Id-event] solution for Id/Access Token confusion and distinct SET = issuer
 
Separate or combined may be evolving. = Mike wants to keep the current backchannel logout very narrowly scoped. = He suggested risc define its own duplicate definitions and = meanings. 
 
That leads me to believe we will have = multi-type events in practice.
 
Session cancellation can occur for = many reasons. One of the differentiators we had tried to make was an = assumption that user initiated events would be part of connect. Risk = would cover variations that drive off of risk calculations like password = reset. 
 
There are also signout events at rp's = to let the OP know. These are not commands but notification that a = resource session is cancelled. IOW single sign out not = expected. 

Phil


On Jun 21, 2017, at 1:58 PM, = John Bradley <ve7jtb@ve7jtb.com> = wrote:

I thought we decided that we are only = allowing set messages form the same family that agree on top level = claims.
 
Otherwise there can be no top level claims = and we are really defining a alternative format to JWT in some ways.
 
John B.
 
On Jun 21, 2017, at 3:54 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
I agree with John that the JWT type = confusion problem and the SET sub problem can and should be discussed = separately. The secevents WG is probably not the right setting to = discuss the former.
 
My = concern with the sub claim is that two profiles may dictate conflicting = semantics (e.g. Profile A says it=E2=80=99s a phone number, Profile B = says it=E2=80=99s an email address). If these profiles don=E2=80=99t = provide an alternate way to declare subject of their events, then they = cannot be present within the same token. This incompatibility trap seems = like something that could be easily missed by groups profiling SET.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From:=  John = Bradley <ve7jtb@ve7jtb.com>
Date:=  Wednesday, June 21, 2017 at 1:39 PM
To:=  Yaron Sheffer <yaronf.ietf@gmail.com>
Cc:=  Justin Richer <jricher@mit.edu>, Marius Scurtescu <mscurtescu@google.com>, Annabelle = Richard <richanna@amazon.com>, = Phil Hunt <phil.hunt@oracle.com>, = Michael Jones <Michael.Jones@microsoft.com>, ID Events Mailing = List <id-event@ietf.org>, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
In the envelope typ is a media/mime = type.  Registering application/idt+jwt if we register jwt as a = structured name sufix.  
 
Using the cty is also possible. =   I need to think about what is better but we can agree on a = convention.
 
Not everything is going = to be a set token like not every JWS is a JWT.
 
If we are going to define processing = rules to stop collisions and confusion around JWT for different = purposes, we should just start using the typ parameter based on the = existing spec.
 
In general content sniffing if there = is more than one option eventually gets you into trouble.
 
I am not convinced that forcing there = to be no sub at the top level is a good idea.  
 
It is not the way we should = differentiate between SET and id_tokens.
 
If sub is not allowed at the top level = people will do non SET JWT for things where the subject is scoped to the = iss of the token.
 
I think defining sub to be part of the = event for cases where the sub is scoped differently from the issuer of = the token is fine, but should not be required for all event types.
 
I think we should solve the confusion = issue separately from the sub issue.
 
Sorry I am at CIS so trying to catch up = on lists.
 
John B.
 
On Jun 17, 2017, at 3:45 = PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
So to summarize what I'm = seeing on this thread:
Everybody agrees with Marius's = short-term solution, specific rules for "sub" and "iss" that can be = defined in the SET spec.
Almost everybody agrees on a long-term "usage" = claim ("type" is taken) that should be defined elsewhere, e.g. in the = JWT BCP.
Did I miss anything?
By the way, if we do add a "usage" claim, we = need to also use it in the SET document before it is published.
Thanks,
    Yaron
 
On 15/06/17 22:08, Justin Richer = wrote:
+1 to this as well.=  
 
 =E2=80=94 Justin
 
On Jun 15, 2017, at 1:09 = PM, Marius Scurtescu <mscurtescu@google.com> wrote:
 
+1 to what Annabelle = said.=  
 
Also, Mike you are missing the other = requirement, for RPs to send events to an IdP. The iss+sub pair at the = top level is broken in this case.

Marius
 
On Wed, Jun 14, 2017 at 5:33 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> = wrote:
+1
 
Phil
 
On Jun 14, 2017, at 5:25 = PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
Mike,
 
Your explanation for why this is a non-problem is dependent = upon side effects of elements of OpenID Connect that were not designed = to solve this issue. As a result, I see several issues with it:

1.      =  The caller of the Token Endpoint is the only party = that can be certain that a nonce-less ID Token is really an ID Token. = Any party that the caller passes the ID Token off to has no way to = verify its provenance.

2.      =  Any future ID Token distribution method needs to = solve this problem again.

3.     =  No other profile of JWT can ever use the "nonce=E2=80=9D= claim.

4.     =  This is only a solution for ID Tokens. Every other = JWT profile that cares about disambiguation has to invent its own = solution to the problem.

 
We = know from experience that naming collisions and replay attacks are both = things that happen. What=E2=80=99s being proposed is a simple, defensive = measure against these risks. You brought up JWT libraries: a general = solution actually makes it easier to use common libraries for JWT = parsing. A =E2=80=9Cusage-aware=E2=80=9D JWT library could handle = disambiguation for any JWT profile, whereas with the status quo each = profile would require unique logic.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From:=  Id-event <id-event-bounces@ietf.org> on behalf of Mike = Jones <Michael.Jones@microsoft.com>
Date:=  Wednesday, June 14, 2017 at 1:16 PM
To:=  Marius Scurtescu <mscurtescu@google.com>
Cc:=  "Richard Backman, Annabelle" <richanna@amazon.com>, ID Events = Mailing List <id-event@ietf.org>, = Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
You=E2=80=99ve heard of =E2=80=9Cpremature = optimization=E2=80=9D.  I=E2=80=99d characterize the proposals in = this thread as =E2=80=9Cpremature pessimation=E2=80=9D =E2=80=93 making = things that can and should be simple complex, without data showing = there=E2=80=99s any need to do so.
 
Mandatory solutions are being proposed in this thread to = problems that there=E2=80=99s no evidence that we actually even = have.  It=E2=80=99s already been established that it=E2=80=99s = impossible for a SET to be confused for an ID Token =E2=80=93 see=  https://www.ietf.org/mail-archive/web/id-event/current/msg00428= .html.  If people have data showing that this is = possible with specific kinds of Access Tokens or other real JWT = deployments, please provide specifics, so that we can use that data to = inform appropriate engineering choices on our part.
 
The proposed =E2=80=9Csolutions=E2=80=9D, such as prohibiting = the use of =E2=80=9Csub=E2=80=9D in the normal way, or requiring a type = claim, would make previously simple things unnecessarily complex.  = Yes, then the result is then different than a normal JWT but a = consequence of this is that custom parsing code would have to be used, = rather than a standard JWT parser.  The more unwieldy we make it to = use SETs, the more likely developers are to just create their own data = structures.  Keeping it simple is the key to adoption.  = Standards are only useful if they are actually used.
 
          &nb= sp;            = ;            &= nbsp;            = -- Mike
 
From:=  Id-event [mailto:id-event-bounces@ietf.org]=  On Behalf Of=  Richard Backman, Annabelle
Sent:=  Tuesday, June 13, 2017 5:33 PM
To:=  Marius Scurtescu <mscurtescu@google.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:=  ID Events Mailing List <id-event@ietf.org>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion and = distinct SET issuer
 
Echoing Marius=E2=80=99s question: can you explain what you = mean by =E2=80=9Cintend=E2=80=9D?
 
To = your first question, I think a better analogy would be the X.509 Key = Usage extension: a multi-valued property that declares the intended = purpose of the JWT, and that a recipient may refer to when determining = whether to accept a JWT being presented to it in some context.
 
-- 
Annabelle Richard Backman
Identity Services
 
 
From:=  Id-event <id-event-bounces@ietf.org> on behalf of Marius = Scurtescu <mscurtescu@google.com>
Date:=  Tuesday, June 13, 2017 at 11:05 AM
To:=  Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc:=  ID Events Mailing List <id-event@ietf.org>
Subject:=  Re: [Id-event] solution for Id/Access Token confusion = and distinct SET issuer
 
On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
And a 2nd question.

What = semantics would "usage" provide that that are not covered via "intend", = "audience", and "scope"?
 
"aud" (audience) specifies the target = client, but not the intended usage (access token to authorize resource = access or SET to communicate a security event?)
 
"scope" is not used by SET.
 
I don't know what do you mean by = "intend" (or intent)?
 
 


Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

=C2=B7We can=E2=80=99t guarantee that every = type of JWT will have a mutually exclusive set of valid claims and/or = header parameters, and enforcing this requires a =E2=80=9Cfail on an = unrecognized claim=E2=80=9D approach to ensure that JWTs from some = future spec can=E2=80=99t be mistaken for JWTs from a current spec.

=C2=B7It is unrealistic to expect implementers = to adhere to the =E2=80=9Cdifferent keys for different kinds of JWTs=E2=80= =9D rule. Whether mandated by the spec or not, implementers will ignore = this because managing one key is easier than managing N different = keys.

=C2=B7Ditto for =E2=80=9Caud=E2=80=9D = and =E2=80=9Ciss=E2=80=9D claims.

+1 for a = =E2=80=9Ctype=E2=80=9D or =E2=80=9Cusage=E2=80=9D claim/header = parameter.

--=  

Annabelle Richard Backman

Identity Services

*From: *Id-event <id-event-bounces@ietf.org> on behalf of Dick = Hardt <dick.hardt@gmail.com>*Date: *Monday, June 12, 2017 at 3:18 PM
*To: = *Marius Scurtescu <mscurtescu@google.com>
*Cc: *Adam = Dawes <adawes@google.com>, = "matake, nov" <nov@matake.jp>, ID = Events Mailing List <id-event@ietf.org>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
*Subject: *Re: [Id-event] solution for Id/Access Token = confusion and distinct SET issuer

Agreed. = Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius = Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>> wrote:

    Thanks for the pointer Dick, = very good timing :-)

    The = issue is described by "2.7. Cross-JWT Confusion" and the
    mitigation is in "3.9. Use Mutually Exclusive = Validation Rules for
    Different Kinds of = JWTs", specifically "Use different sets of
    = required claims...", "Use different keys for different kinds of
    JWTs." and "Use different issuers for different = kinds of JWTs.".

    I still = think that a "type" claim would bring a lot of clarity and
    safety.


    Marius

  =   On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <dick.hardt@gmail.com
  =   <mailto:dick.hardt@gmail.com>> wrote:

        Yaron, Mike and I = just published an BCP ID for JWT
      =  =  http://self-issued.info/?p=3D1690

        On Thu, Jun 8, 2017 at 9:02 PM = Adam Dawes <adawes@google.com
        <mailto:adawes@google.com>> wrote:

            I = was initially a fan of keeping SETS to be very similar to
            id tokens but I now = think this is a better plan.

    =         On Thu, Jun 8, 2017 at 6:56 PM matake, nov = <nov@matake.jp
    =         <mailto:nov@matake.jp>> wrote:

                +1 = especially for "type"

      =           2017-06-09 10:32 GMT+09:00 Phil Hunt = (IDM)
              =   <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:

            =         +1

  =                   Phil


        =              > On Jun 8, 2017, at = 6:28 PM, Marius Scurtescu
        =             <mscurtescu@google.com
      =               <mailto:mscurtescu@google.com>> wrote:
                =      >
        =              > There were a couple = of proposals on how to
          =           distinguish SETs from Id Tokens and = Access Tokens in
            =         such a way that naive implementations will = not
              =       confuse one for the other and open up security
                =     vulnerabilities.
        =              >
  =                   =  > There is also another important requirement: the
                =     SET issuer in some cases must be different from the
                =     "sub" issuer. This is the case of an RP sending SETs
                =     to an IdP.
        =              >
  =                   =  > With these requirements in mind I propose the
                =     following:
        =              > - both "sub" and = "iss" to be defined at the event
      =               level
                =      > - "iss" at event level and at top SET level = can
              =       be different
      =                > - "iss" and = "sub" at event level can be different
      =               across events in the = same SET
              =        > - "sub" should NOT be present at the top = SET
              =       level (this solves the disambiguation), please = note
              =       "should" and not "must"
    =                  >
                =      > This solution also allows different profiles = that
              =       define event types to define additional claims
                =     related to sub (like email or phone_number) and
                =     since all these claims will be at the event level
                =     there will be no collisions or ambiguity.
                =      >
        =              > Another proposal = (which I supported) was to
        =             define a composite "aud" = claim. This is not solving
        =             the requirement for a = distinct  SET issuer. Also,
      =               having the same claim = name having different syntax
        =             in different token types could = lead to confusion.
          =            >
  =                   =  > And yet another proposal was to introduce a new
                =     claim for JWTs that defines a "type". This is not
                =     practical in the short term, and it also is not
                =     solving the distinct issuer requirement, but I think
                =     this is something the JWT group should seriously
                =     consider.
          =            >
  =                   =  > Thoughts?
          =            >
  =                   =  > Marius

      =                > = _______________________________________________
  =                   =  > Id-event mailing list
                =      >=  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =                  >
                =    =  https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DJmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=3D5xQqvBiXZ6= Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=3D

                =     _______________________________________________
                =     Id-event mailing list
      =              =  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =                =  https://www.ietf.org/mailman/listinfo/id-event

            =     _______________________________________________
                = Id-event mailing list
          =      =  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =            =  https://www.ietf.org/mailman/listinfo/id-event

            = --=  
            = Adam Dawes | Sr. Product Manager |adawes@google.com
    =         <mailto:adawes@google.com> |+1 650-214-2410
  =           <tel:(650)%20214-2410>

            = _______________________________________________
  =           Id-event mailing list
           =  Id-event@ietf.org=  <mailto:Id-event@ietf.org>
    =        =  https://www.ietf.org/mailman/listinfo/id-event

        --=  
        Subscribe to the = HARDTWARE <http://hardtware.com/> mail list to
        learn about projects I am working = on!



--=  

Subscribe to the HARDTWARE = <http://hardtware.com/> mail list to learn about = projects I am working on!



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
<= div class=3D"">
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
 
_______________________________________________Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
 
 

= --Apple-Mail=_25A110D7-5E24-4523-BFE5-2BB04161A6EC-- From nobody Wed Jun 28 17:08:30 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D55126D85 for ; Wed, 28 Jun 2017 17:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF2oQ7zZ6Gx4 for ; Wed, 28 Jun 2017 17:08:26 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77D3126C83 for ; Wed, 28 Jun 2017 17:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z4dE7ympslvyt7nps8xdIOulXln97U0Jgh1Te+vYjbY=; b=dry8t6McwA/vNJu605gxDBRt2C2frphYkasOrrj5J7KDrPtzw7gKsn3WfxHcSYcNLPTGuN8v1bzQ1McKpNT+NSr4iFcSCBIHFuGYclhSdeY7wwFqjrHm52k+HIUDLEbkLAu7gJqtOF/1JRSIikf2c87s1Ok5J3VOhGfv+4Vq+uA= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.3; Thu, 29 Jun 2017 00:08:24 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.001; Thu, 29 Jun 2017 00:08:24 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: Heads-up about SET spec updates Thread-Index: AdLwa3VhxmOh1ap9Sxqj4ofmRP4gvA== Date: Thu, 29 Jun 2017 00:08:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-28T17:08:22.8061128-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:+t1gE7VJ1rS6Rtto6huDAllBswYGshf0BlOAIP4djaYeTvuBAZdPE1O9/ldl5r1S6AzLSZ2fvzHsMBzz79Bp/0L1rrF01wPltopk4dfaIZZAbOnRq61r53j4hB/y6vlkgKExBezmeNANpqsmgiUV6/q0eEWxBvBT51su3ZQFyEuIb5dagCz2UWsJ7ZmOA1gEnPM5FLhUxUCyVs1j6HkJE35OI8M59lBnsINwXxzOEwuUVz2YG6iAAwyPgeDGXChPQcVP1gQ7tMey7zq7mGJHY07uj7GdfCQYoW04rB8fKvAn6ZoqR/Qh2R9+/uEVKuCx3eNASVBkuHOg7ki6zXrvG+XtnFgdbeGURX8zjmbglV/BTeO0eJ41OWb5g4AfBvOyCC78jTXT/YNU+6epGykPmw25ycSfy9wNdFKKNNhjlbgBL1nruhOzeVSlxTHuLt/RORfWLLVaLI7sdzAb8Jh2TK/HVaViwo4cNcaEEtIQunQoUk+/uarbwOsg39cx2YaNjZKbJjSULWYEXbqM0IK14AO8naNOl2H2H48cIYRuL5cEiP0+y9JaHAV6JU5zHxbiz/I9cMaaVxSWh2ZS+NS1ovpqv/GED4ymzJ4oGWExILYuMxxw3iAHktNg4gB3S74fYVbM08BgdEqufcYv8SSMKSwGhNFkQnFLjoN7zfj4jG1445G5FzkXoWrpfT/j5LM6Vx0NDWF8YzJ9nq0p26JSIIgqrDHaHyXvEpAhDbfnOKS/pe7fbkrTkP3Z94qdjW426rpHFjRjRwsY7yLgZ8Dgg9oXsKMueuFbinRGwxU6fSTO7bmY0yys0NChpMwIxnUH x-ms-office365-filtering-correlation-id: 80d484ff-9097-4004-1a85-08d4be82f59a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603020)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0119; x-ms-traffictypediagnostic: CY4PR21MB0119: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(167848164394848); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910014)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0119; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39850400002)(39410400002)(39840400002)(39400400002)(39450400003)(33656002)(2420400007)(86362001)(5630700001)(8936002)(15650500001)(3660700001)(3280700002)(86612001)(2900100001)(77096006)(7110500001)(7696004)(10090500001)(189998001)(2501003)(5005710100001)(2351001)(74316002)(8990500004)(53936002)(110136004)(6916009)(10710500007)(54356999)(50986999)(2906002)(236005)(9686003)(6306002)(38730400002)(5640700003)(99286003)(55016002)(478600001)(5660300001)(72206003)(6506006)(10290500003)(81166006)(102836003)(25786009)(6436002)(790700001)(7736002)(6116002)(8676002)(14454004)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504DCC5E0C79B97C1607479F5D20CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2017 00:08:24.0063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119 Archived-At: Subject: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:08:28 -0000 --_000_CY4PR21MB0504DCC5E0C79B97C1607479F5D20CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, I wanted to give you a heads-up about two SET spec updates in the current e= ditor's draft before they are published. The first solves the potential ID Token / SET confusion problem by requirin= g that SETs not include a top-level "exp" claim when ID Tokens could also b= e generated by the same issuer. Because "exp" is a required ID Token claim= , SETs would therefore be rejected by existing ID Token validation code. N= ote that this solution is already recommended in the specification. The ed= itor's draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in Chicag= o and that has been the subject of much discussion since. The second adds the following new section: Requirements for SET Profiles Profile Specifications for SETs define the syntax and semantics of SETs con= forming to that SET profile and rules for validating those SETs. The syntax= defined by profiling specifications includes what claims and event payload= values are used by SETs utilizing the profile. Defining the semantics of the SET contents for SETs utilizing the profile i= s equally important. Possibly most important is defining the procedures use= d to validate the SET issuer and to obtain the keys controlled by the issue= r that were used for cryptographic operations used in the JWT representing = the SET. For instance, some profiles may define an algorithm for retrieving= the SET issuer's keys that uses the iss claim value as its input. Profile Specifications MUST clearly specify the steps that a recipient of a= SET utilizing that profile MUST perform to validate that the SET is both s= yntactically and semantically valid. It's included to inform profile writers about what they must do to be able = to use SETs securely. While much of the discussion as of late has been abo= ut syntax, semantics is equally important, and must be considered by profil= e writers and deployers. I believe that the new section contains only statements that are already fa= ctually accurate requirements but that were previously unstated. The edito= r's draft makes these requirements explicit. Feedback on how to make these= requirements even more clear, is of course, welcomed. Best wishes= , -- Mike --_000_CY4PR21MB0504DCC5E0C79B97C1607479F5D20CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I wanted to give you a heads-up about two SET spec u= pdates in the current editor’s draft before they are published.<= /o:p>

 

The first solves the potential ID Token / SET confus= ion problem by requiring that SETs not include a top-level “exp”= ; claim when ID Tokens could also be generated by the same issuer.  Be= cause “exp” is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note tha= t this solution is already recommended in the specification.  The edit= or’s draft update makes this solution mandatory.  This provides = a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

 

The second adds the following new section:

 

Requirements for SET Profiles

 

Profile Specifications for SETs define the syntax = and semantics of SETs conforming to that SET profile and rules for validati= ng those SETs. The syntax defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

 

Defining the semantics of the SET contents for SET= s utilizing the profile is equally important. Possibly most important is de= fining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's key= s that uses the iss claim value as= its input.

 

Profile Specifications MUST clearly specify the st= eps that a recipient of a SET utilizing that profile MUST perform to valida= te that the SET is both syntactically and semantically valid.

 

It’s included to inform profile writers about = what they must do to be able to use SETs securely.  While much of the = discussion as of late has been about syntax, semantics is equally important= , and must be considered by profile writers and deployers.

 

I believe that the new section contains only stateme= nts that are already factually accurate requirements but that were previous= ly unstated.  The editor’s draft makes these requirements explic= it.  Feedback on how to make these requirements even more clear, is of course, welcomed.

 

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

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

 

--_000_CY4PR21MB0504DCC5E0C79B97C1607479F5D20CY4PR21MB0504namp_-- From nobody Wed Jun 28 17:24:44 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C279A126C83 for ; Wed, 28 Jun 2017 17:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64pR-HvTx86M for ; Wed, 28 Jun 2017 17:24:40 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FB0126C23 for ; Wed, 28 Jun 2017 17:24:40 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id 16so64611388qkg.2 for ; Wed, 28 Jun 2017 17:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7hnRZZZj68dfzrqQknMhcbdMmwS8vre1OhRPQtAZjnE=; b=mnMXySvwvdNPfovu0VsQ/GgqiJ/gBQkBbSwDGe+6D0v1tiaTBpq/44eLxbqJeNt/sh dSZ9ICBQ2dOqqierDsZiMB0tok/H7Hhy3rnzSGYT5nDlH1XzqPhQ2jykIpu76P8/erjq LjZZ7gTWzfHiWKdwOSC3qAQdROuPQXhoPH34AIVDXpHLjtRY9NG2fUhJCNv91cTsVRhg ax5afu85cJenLBFBy0fFm6iZi4DL25DTZjRLj24tLeelefCXkgnAdEJ1MMVcDkMw0SJr jqmpYRzoBh0msBKO+yVPF35i3JnPpXUYa1I5v25NbgtHgmZH0K+lLXwjIPfVHbKsIAqv U83A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7hnRZZZj68dfzrqQknMhcbdMmwS8vre1OhRPQtAZjnE=; b=Sh9QNJSslrcg0LiNeUy0y9paymVYrGivh4i11y+VzNLPPeBNZhTPjI7j0s0tqwb9UP KoYwuOsyEVFzRJeCQeewLMyNL9ooSTDV/M886Tr/ubXACZJYXNQYgrB63vvUJGfUvJHF AnBIHxF0dqng4FhvZjeONsQOa4KnLmXslX4XR8JlyL2L8fPza8RI09UQjW6mzKgagr9X uET7jeB+l31JUwhY4/8lA6h0FEDy96ZH8LExlMN2PKXPpjehZ8uTJNApxAGV0ynfI4cY tD7+bALM7CxNTnHrGeP1Vaz050uwt9qWD2OVUwJ+/H2/Aob5Fym23S8oef6fYMDRQNLU +FPw== X-Gm-Message-State: AKS2vOwRn61L/pF8k1yjOEDluF2kF2Bu2jNcK7SjIPZ63ZhAM2rz1p8Z 2VIo9WA3Crih77gVviNSBSbXYm9xds0f X-Received: by 10.55.150.134 with SMTP id y128mr15546841qkd.29.1498695878881; Wed, 28 Jun 2017 17:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Wed, 28 Jun 2017 17:24:18 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Wed, 28 Jun 2017 17:24:18 -0700 Message-ID: To: Mike Jones Cc: "id-event@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c08b82c7d723b05530e5364" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:24:43 -0000 --94eb2c08b82c7d723b05530e5364 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Mike for working on this. I'm very happy with the change regarding the "exp" claim, and believe it is the best resolution to the "ID Token" confusion concern. By making the "exp" claim that is already NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee that is desired, allowing these two types of JWTs to be used with a common issuer. This also allows "sub" to be used for its intended purpose (as defined by RFC7519) without modification, which other working groups that wish to profile SET have expressed an interest to do The benefit the community will gain from the SET standard overall is a standard way to express events that won't conflict with ID Token (no "iss" partitioning required). With Mike's changes we achieve that, and in a way that retains the original simplicity, extensibility and generalizability goals of SET by not redefining any of JWT's standard claims. On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones wrote: > Hi folks, > > > > I wanted to give you a heads-up about two SET spec updates in the current > editor=E2=80=99s draft before they are published. > > > > The first solves the potential ID Token / SET confusion problem by > requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim w= hen ID Tokens > could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID > Token claim, SETs would therefore be rejected by existing ID Token > validation code. Note that this solution is already recommended in the > specification. The editor=E2=80=99s draft update makes this solution man= datory. > This provides a simple and durable solution to the problem we agreed to > solve at IETF 98 in Chicago and that has been the subject of much > discussion since. > > > > The second adds the following new section: > > > > Requirements for SET Profiles > > > > Profile Specifications for SETs define the syntax and semantics of SETs > conforming to that SET profile and rules for validating those SETs. The > syntax defined by profiling specifications includes what claims and event > payload values are used by SETs utilizing the profile. > > > > Defining the semantics of the SET contents for SETs utilizing the profile > is equally important. Possibly most important is defining the procedures > used to validate the SET issuer and to obtain the keys controlled by the > issuer that were used for cryptographic operations used in the JWT > representing the SET. For instance, some profiles may define an algorithm > for retrieving the SET issuer's keys that uses the iss claim value as its > input. > > > > Profile Specifications MUST clearly specify the steps that a recipient of > a SET utilizing that profile MUST perform to validate that the SET is bot= h > syntactically and semantically valid. > > > > It=E2=80=99s included to inform profile writers about what they must do t= o be able > to use SETs securely. While much of the discussion as of late has been > about syntax, semantics is equally important, and must be considered by > profile writers and deployers. > > > > I believe that the new section contains only statements that are already > factually accurate requirements but that were previously unstated. The > editor=E2=80=99s draft makes these requirements explicit. Feedback on ho= w to make > these requirements even more clear, is of course, welcomed. > > > > Best > wishes, > > -- Mike > > > --94eb2c08b82c7d723b05530e5364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Mike for working on this. I'm very happ= y with the change regarding the "exp" claim, and believe it is th= e best resolution to the "ID Token" confusion concern.
=



On Wed, Jun 28, 2017 at= 5:08 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:

Hi folks,

=C2=A0

I wanted to give you a heads-up about two SET spec u= pdates in the current editor=E2=80=99s draft before they are published.<= /u>

=C2=A0

The first solves the potential ID Token / SET confus= ion problem by requiring that SETs not include a top-level =E2=80=9Cexp=E2= =80=9D claim when ID Tokens could also be generated by the same issuer.=C2= =A0 Because =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.=C2=A0 Note tha= t this solution is already recommended in the specification.=C2=A0 The edit= or=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provide= s a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

=C2=A0

The second adds the following new section:=

=C2=A0

Requirements for SET Profiles

=C2=A0

Profile Specifications for SETs define the syntax = and semantics of SETs conforming to that SET profile and rules for validati= ng those SETs. The syntax defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

=C2=A0

Defining the semantics of the SET contents for SET= s utilizing the profile is equally important. Possibly most important is de= fining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's= keys that uses the iss claim value as= its input.

=C2=A0

Profile Specifications MUST clearly specify the st= eps that a recipient of a SET utilizing that profile MUST perform to valida= te that the SET is both syntactically and semantically valid.

=C2=A0

It=E2=80=99s included to inform profile writers abou= t what they must do to be able to use SETs securely.=C2=A0 While much of th= e discussion as of late has been about syntax, semantics is equally importa= nt, and must be considered by profile writers and deployers.

=C2=A0

I believe that the new section contains only stateme= nts that are already factually accurate requirements but that were previous= ly unstated.=C2=A0 The editor=E2=80=99s draft makes these requirements expl= icit.=C2=A0 Feedback on how to make these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0


--94eb2c08b82c7d723b05530e5364-- From nobody Wed Jun 28 17:38:54 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0960B126B7F for ; Wed, 28 Jun 2017 17:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VUaX6KP1J4A for ; Wed, 28 Jun 2017 17:38:51 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB251200ED for ; Wed, 28 Jun 2017 17:38:51 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5T0cma5018532 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 00:38:49 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5T0cmYK024915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 00:38:48 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5T0clHc003929; Thu, 29 Jun 2017 00:38:47 GMT Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Jun 2017 17:38:47 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-19CE5D47-FB37-4C8C-8876-05E9716109BC Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 28 Jun 2017 17:38:45 -0700 Cc: Mike Jones , "id-event@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: William Denniss X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 00:38:54 -0000 --Apple-Mail-19CE5D47-FB37-4C8C-8876-05E9716109BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree on the exp part.=20 Regarding the second part. I would like to see more discussion.=20 For example, in the the use cases, there may be compatibility issues if diff= erent set profiles cannot be sent over the same stream.=20 Such profiles should avoid things like requiring signing and encryption with= out consideration regarding how they are transferred. Also key management m= ight be better tied up in how the streams are manages because the network re= lationship may define the requirements rather than the data.=20 My initial reaction is, the profiles should stick to the data and valid inte= rpretation.=20 If the group agrees I will merge the exp and post over the weekend.=20 I can merge the second part if there is a strong agreement to do so.=20 Thanks! Phil > On Jun 28, 2017, at 5:24 PM, William Denniss wrote: >=20 > Thank you Mike for working on this. I'm very happy with the change regardi= ng the "exp" claim, and believe it is the best resolution to the "ID Token" c= onfusion concern. >=20 > By making the "exp" claim that is already NOT RECOMMENDED in the current d= raft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee t= hat is desired, allowing these two types of JWTs to be used with a common is= suer. This also allows "sub" to be used for its intended purpose (as defined= by RFC7519) without modification, which other working groups that wish to p= rofile SET have expressed an interest to do >=20 > The benefit the community will gain from the SET standard overall is a sta= ndard way to express events that won't conflict with ID Token (no "iss" part= itioning required). With Mike's changes we achieve that, and in a way that r= etains the original simplicity, extensibility and generalizability goals of S= ET by not redefining any of JWT's standard claims. >=20 >=20 >> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = wrote: >> Hi folks, >>=20 >> =20 >>=20 >> I wanted to give you a heads-up about two SET spec updates in the current= editor=E2=80=99s draft before they are published. >>=20 >> =20 >>=20 >> The first solves the potential ID Token / SET confusion problem by requir= ing that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when ID To= kens could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID Token claim, SETs would therefore be rejected by existi= ng ID Token validation code. Note that this solution is already recommended= in the specification. The editor=E2=80=99s draft update makes this solutio= n mandatory. This provides a simple and durable solution to the problem we a= greed to solve at IETF 98 in Chicago and that has been the subject of much d= iscussion since. >>=20 >> =20 >>=20 >> The second adds the following new section: >>=20 >> =20 >>=20 >> Requirements for SET Profiles >> =20 >> Profile Specifications for SETs define the syntax and semantics of SETs c= onforming to that SET profile and rules for validating those SETs. The synta= x defined by profiling specifications includes what claims and event payload= values are used by SETs utilizing the profile. >> =20 >> Defining the semantics of the SET contents for SETs utilizing the profile= is equally important. Possibly most important is defining the procedures us= ed to validate the SET issuer and to obtain the keys controlled by the issue= r that were used for cryptographic operations used in the JWT representing t= he SET. For instance, some profiles may define an algorithm for retrieving t= he SET issuer's keys that uses the iss claim value as its input. >> =20 >> Profile Specifications MUST clearly specify the steps that a recipient of= a SET utilizing that profile MUST perform to validate that the SET is both s= yntactically and semantically valid. >> =20 >>=20 >> It=E2=80=99s included to inform profile writers about what they must do t= o be able to use SETs securely. While much of the discussion as of late has= been about syntax, semantics is equally important, and must be considered b= y profile writers and deployers. >>=20 >> =20 >>=20 >> I believe that the new section contains only statements that are already f= actually accurate requirements but that were previously unstated. The edito= r=E2=80=99s draft makes these requirements explicit. Feedback on how to mak= e these requirements even more clear, is of course, welcomed. >>=20 >> =20 >>=20 >> Best wish= es, >>=20 >> -- Mike >>=20 >> =20 >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057S= bK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-CzSt= qOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=3D= =20 --Apple-Mail-19CE5D47-FB37-4C8C-8876-05E9716109BC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree on the exp part. 

Regard= ing the second part. I would like to see more discussion. 

For example= , in the the use cases, there may be compatibility issues if different set p= rofiles cannot be sent over the same stream. 

Such profiles should avo= id things like requiring signing and encryption without consideration regard= ing how they are transferred.  Also key management might be better tied= up in how the streams are manages because the network relationship may defi= ne the requirements rather than the data. 

My initial reaction is, the= profiles should stick to the data and valid interpretation. 

If= the group agrees I will merge the exp and post over the weekend. 

I c= an merge the second part if there is a strong agreement to do so. 

Tha= nks!

Phil

On Jun 28, 2= 017, at 5:24 PM, William Denniss <= wdenniss@google.com> wrote:

Thank you Mike for working on this. I'm very happy w= ith the change regarding the "exp" claim, and believe it is the best resolut= ion to the "ID Token" confusion concern.

By making t= he "exp" claim that is already NOT RECOMMENDED in the current draft a MUST NOT, w= e can provide the ID Tokens and SET uniqueness guarantee that is desired, al= lowing these two types of JWTs to be used with a common issuer. This also al= lows "sub" to be used for its intended purpose (as defined by RFC7519) witho= ut modification, which other working groups that wish to profile SET have ex= pressed an interest to do

The benefit the community= will gain from the SET standard overall is a standard way to express events= that won't conflict with ID Token (no "iss" partitioning required). With Mi= ke's changes we achieve that, and in a way that retains the original simplic= ity, extensibility and generalizability goals of SET by not redefining any o= f JWT's standard claims.


On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones= <Michael.Jones@microsoft.com> wrote:

Hi folks,

 

I wanted to give you a heads-up about two SET spec up= dates in the current editor=E2=80=99s draft before they are published.

 

The first solves the potential ID Token / SET confusi= on problem by requiring that SETs not include a top-level =E2=80=9Cexp=E2=80= =9D claim when ID Tokens could also be generated by the same issuer.  B= ecause =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note that= this solution is already recommended in the specification.  The editor= =E2=80=99s draft update makes this solution mandatory.  This provides a= simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discus= sion since.

 

The second adds the following new section:<= /u>

 

= Requirements for SET Profiles

 

Profile Specifications for SETs define the syntax an= d semantics of SETs conforming to that SET profile and rules for validating t= hose SETs. The syntax defined by profiling specifications includes what claims and event payload values are used by SE= Ts utilizing the profile.

 

Defining the semantics of the SET contents for SETs u= tilizing the profile is equally important. Possibly most important is defini= ng the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for c= ryptographic operations used in the JWT representing the SET. For instance, s= ome profiles may define an algorithm for retrieving the SET issuer's keys th= at uses the iss claim value as it= s input.

 

Profile Specifications MUST clearly specify the step= s that a recipient of a SET utilizing that profile MUST perform to validate t= hat the SET is both syntactically and semantically valid.

 

It=E2=80=99s included to inform profile writers about= what they must do to be able to use SETs securely.  While much of the d= iscussion as of late has been about syntax, semantics is equally important, a= nd must be considered by profile writers and deployers.

 

I believe that the new section contains only statemen= ts that are already factually accurate requirements but that were previously= unstated.  The editor=E2=80=99s draft makes these requirements explici= t.  Feedback on how to make these requirements even more clear, is of course, welcomed.

 

         = ;            &nb= sp;           &n= bsp;            =             &nbs= p;     Best wishes,

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

 


= --Apple-Mail-19CE5D47-FB37-4C8C-8876-05E9716109BC-- From nobody Thu Jun 29 10:37:14 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AAB1200B9 for ; Thu, 29 Jun 2017 10:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPfWYtFHbUCb for ; Thu, 29 Jun 2017 10:37:11 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21F5129B7E for ; Thu, 29 Jun 2017 10:37:10 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 32so80409972qtv.1 for ; Thu, 29 Jun 2017 10:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sW290efT/lmNcT3Q2UBob+N+FuK4aOOdhgD1fMKT+DM=; b=08AbusyQQ4NZmZFfEkwAA1rL2rHlSxEwpN45z3fUHs+6MLEmB6eqVsiUyNceq3dg74 hhIVTCL5ItazULs2S3IOUMVS8Kxl9wSJqCOxLQdBAVF/35YscSfSAzaoFeNVS/GxoRsM nlxkd0AE2AUWIIwuYYDV6I1ItWPvrB7RcKGUCYaEerhOnXSaTghrGGCAWORlFP1/R+FZ WkPbndpqz2Jxph1I8JDUyBWA7IP2nfXSkDpUG1XZVK0qvTDoOLhpgZs82j3PSCKMt2iT Wpd2J5MwCc3oBd10P6wCQ0NTzUHGNjDpe1M3k0ZDgAjw3yNPOgQt6m9Y5IFgj9F6b3wz Ct5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sW290efT/lmNcT3Q2UBob+N+FuK4aOOdhgD1fMKT+DM=; b=Ixls1MFW4OfgBK7E08OHfRGc+0LWmYjRZTBC/4fsX9SDAU6Msh5aGk2/+qiIhJSF6l rYUyd78+kJzBD6bmwDLD2RMSPoam21QYF3huuhCpUyVC3AniJfT+v2oL+kBzcKAH/7xb 3cYeuxQHOSBk4CWab60yFVh2LNom/2NhKuMy+7JALsmfw9Cz4DZ6+EDYE69ybLuQ/RRu 7ALwIFSY4Q/hDav0I6GdQmX0ryQX3l/VeHW0yBHqqphdx0tnkmq/wMMxDxQqOo7/rkFc RpAT9+PK+3ryKt4H61L4Myxkq1Bqfk4dlT8T75kjjT4XkHP018/R4kuum1m1IZi7qBOW GWQQ== X-Gm-Message-State: AKS2vOyNuYnSUGtlTP20rHklmhkyBQF52iXZIy9wpyFjKYLBvFcaOQnR 2XdG+19uFZpb3keA X-Received: by 10.200.50.93 with SMTP id y29mr21784591qta.108.1498757829732; Thu, 29 Jun 2017 10:37:09 -0700 (PDT) Received: from johns-mbp.lan ([191.115.107.144]) by smtp.gmail.com with ESMTPSA id b28sm4771785qte.23.2017.06.29.10.37.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 10:37:09 -0700 (PDT) From: John Bradley Message-Id: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 13:37:04 -0400 In-Reply-To: Cc: William Denniss , Michael Jones , "id-event@ietf.org" To: "Phil Hunt (IDM)" References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1137b8341082a105531cc02d" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:37:14 -0000 --001a1137b8341082a105531cc02d Content-Type: multipart/alternative; boundary="Apple-Mail=_8E44945B-DED7-4487-B836-B6DB509D3411" --Apple-Mail=_8E44945B-DED7-4487-B836-B6DB509D3411 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree on exp. I think defining trust relationships should be in the profiles as they = may be quite different. That is why mixing events in the same message will be a problem. I = thought we agreed on that. Trying to define a fixed trust relationship for the transport is likely = going to cause people to roll there own. Even in Connect for specific verticals like finance we see diffrences in = registration etc to reflect the need to accommodate eIDS and other = regulations. One size fits all is great if you are the one size. =20 I do think we should encourage people to use JWKS URI discovers from = issuer meta-data based on the issuers well-known as a pattern that has = proven to be repeatable.=20 It would be nice if we had those specs done in the IETF:) John B. > On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) = wrote: >=20 > I agree on the exp part.=20 >=20 > Regarding the second part. I would like to see more discussion.=20 >=20 > For example, in the the use cases, there may be compatibility issues = if different set profiles cannot be sent over the same stream.=20 >=20 > Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred. = Also key management might be better tied up in how the streams are = manages because the network relationship may define the requirements = rather than the data.=20 >=20 > My initial reaction is, the profiles should stick to the data and = valid interpretation.=20 >=20 > If the group agrees I will merge the exp and post over the weekend.=20 >=20 > I can merge the second part if there is a strong agreement to do so.=20= >=20 > Thanks! >=20 > Phil >=20 > On Jun 28, 2017, at 5:24 PM, William Denniss > wrote: >=20 >> Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. >>=20 >> By making the "exp" claim that is already = NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to do >>=20 >> The benefit the community will gain from the SET standard overall is = a standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. >>=20 >>=20 >> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: >> Hi folks, >>=20 >> =20 >>=20 >> I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. >>=20 >> =20 >>=20 >> The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. >>=20 >> =20 >>=20 >> The second adds the following new section: >>=20 >> =20 >>=20 >> Requirements for SET Profiles <> >> =20 >> Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. >> =20 >> Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. >> =20 >> Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid.=20 >> =20 >>=20 >> It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. >>=20 >> =20 >>=20 >> I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. >>=20 >> =20 >>=20 >> Best = wishes, >>=20 >> -- = Mike >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D = =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_8E44945B-DED7-4487-B836-B6DB509D3411 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree on exp.

I think defining trust relationships should be in the = profiles as they may be quite different.

That is why mixing events in the same = message will be a problem.  I thought we agreed on that.

Trying to define a fixed = trust relationship for the transport is likely going to cause people to = roll there own.

Even in Connect for specific verticals like finance we see = diffrences in registration etc to reflect the need to accommodate eIDS = and other regulations.

One size fits all is great if you are the one size. =  

I do = think we should encourage people to use JWKS URI discovers from issuer = meta-data based on the issuers well-known as a pattern that has proven = to be repeatable. 

It would be nice if we had those specs done in the = IETF:)

John = B.


On = Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

I = agree on the exp part. 

Regarding the second part. I = would like to see more discussion. 

For example, in the the use = cases, there may be compatibility issues if different set profiles = cannot be sent over the same stream. 

Such profiles should avoid = things like requiring signing and encryption without consideration = regarding how they are transferred.  Also key management might be = better tied up in how the streams are manages because the network = relationship may define the requirements rather than the = data. 

My = initial reaction is, the profiles should stick to the data and valid = interpretation. 

If the group agrees I = will merge the exp and post over the weekend. 
I can merge the second part = if there is a strong agreement to do so. 
Thanks!
Phil

On Jun 28, = 2017, at 5:24 PM, William Denniss <wdenniss@google.com>= wrote:

Thank you Mike for working on this. I'm very happy with the = change regarding the "exp" claim, and believe it is the best resolution = to the "ID Token" confusion concern.

By making the "exp" claim that is already NOT RECOMMENDED in the = current draft a MUST NOT, we can provide the ID Tokens and SET = uniqueness guarantee that is desired, allowing these two types of JWTs = to be used with a common issuer. This also allows "sub" to be used for = its intended purpose (as defined by RFC7519) without modification, which = other working groups that wish to profile SET have expressed an interest = to do

The = benefit the community will gain from the SET standard overall is a = standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims.


On Wed, = Jun 28, 2017 at 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi = folks,

 

I = wanted to give you a heads-up about two SET spec updates in the current = editor=E2=80=99s draft before they are published.

 

The first solves the potential = ID Token / SET confusion problem by requiring that SETs not include a = top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also be = generated by the same issuer.  Because =E2=80=9Cexp=E2=80=9D is a = required ID Token claim, SETs would therefore be rejected by existing ID = Token validation code.  Note that this solution is already = recommended in the specification.  The editor=E2=80=99s draft = update makes this solution mandatory.  This provides a simple and = durable solution to the problem we agreed to solve at IETF 98 in Chicago = and that has been the subject of much discussion since.

 

The = second adds the following new section:

 

Requirements= for SET Profiles

 

Profile Specifications for SETs define = the syntax and semantics of SETs conforming to that SET profile and = rules for validating those SETs. The syntax defined by profiling = specifications includes what claims and event payload values are used by = SETs utilizing the profile.

 

Defining the semantics of the SET = contents for SETs utilizing the profile is equally important. Possibly = most important is defining the procedures used to validate the SET = issuer and to obtain the keys controlled by the issuer that were used = for cryptographic operations used in the JWT representing the SET. For = instance, some profiles may define an algorithm for retrieving the SET = issuer's keys that uses the iss claim value as its input.

 

Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid. 

 

It=E2=80= =99s included to inform profile writers about what they must do to be = able to use SETs securely.  While much of the discussion as of late = has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers.

 

I believe that the new section = contains only statements that are already factually accurate = requirements but that were previously unstated.  The editor=E2=80=99s= draft makes these requirements explicit.  Feedback on how to make = these requirements even more clear, is of course, welcomed.

 

         =             &n= bsp;                  &nb= sp;            = ;           Best wishes,

         =             &n= bsp;                  &nb= sp;            = ;           -- Mike

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3D_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2= KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=3D 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_8E44945B-DED7-4487-B836-B6DB509D3411-- --001a1137b8341082a105531cc02d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIEO9q84VPRiQ0CpzoAZzXsOEU/2z KZgrOhbgbjx3PQgNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYyOTE3MzcxMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCTVusV3ilekI3goC8OIuENap0nHyDeUi2Di/ab82o7kCDc kszX1R1/Yrj7PPsPZsmfk4hWXmRyPZwjKUjJwbScJ8esfFQFGSyjRfA+iXW6Ms/gH2c0xYczpULh AWdmC1xCJzyzpeW+a9u9yPX5IpE0FCtbzmGJi+ZOaABY8vFkqAbUtpnlnWH3hlw1OUJZjTRoHfIY ziosxc4WWi0sLK7fHPAkEtJM1D0kzIWw9+D0kl/xBnFXAvcbFmE4ML3rkUX++8YfEpbKXFwpscmT s25l3Cg3F6/RgvHRFy3mbh7oyomQmqd5znO7o19ZSC/OBdkL9q5WkPBxSkzFjarHRcfn --001a1137b8341082a105531cc02d-- From nobody Thu Jun 29 10:46:41 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9A12EBF6 for ; Thu, 29 Jun 2017 10:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=openconsentgroup.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSXgDiEU3VHn for ; Thu, 29 Jun 2017 10:46:38 -0700 (PDT) Received: from n1nlsmtp03.shr.prod.ams1.secureserver.net (n1nlsmtp03.shr.prod.ams1.secureserver.net [188.121.43.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698D21289B0 for ; Thu, 29 Jun 2017 10:46:38 -0700 (PDT) Received: from n1plcpnl0072.prod.ams1.secureserver.net ([188.121.57.6]) by : HOSTING RELAY : with SMTP id QdVYdV6pVxbb9QdVYdk1YH; Thu, 29 Jun 2017 10:45:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openconsentgroup.com; s=default; h=References:To:Cc:In-Reply-To:Date: Subject:Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TLLhWzCfA/ew4i1EKP0HTYhPPIV2keUHdAzt+3CXnUs=; b=j8QEk+mkroAA6x+OZF0EdUEVT SQB1hfwUH5ENPYQAzfXhdr6qLwzEi8cnSEsTwnkkLsUTL8fd+XtlHd95iAzae60k+w23aCqC7ryM7 2WDvikmmJ6dFJOOmYIb4tIVDy8cEgyBG+sAyst4BQENuWdXc1CSwTTiVyye/xks5BVknaR9B5ui/7 NHndWM6laibduoJquH1Juo9y9belbCi5lwkyk+9bAah+RBZCFEjXKoutJi+XdX9JKXaqRBIg5BYPZ tnFz2F3WtCq7aJ9LbHRmLpvlutjRvWMyiPtiylTXSBF6Xm+Z6bYnISbcZ8waL2EJ8N7ZFJ70KApbe 5F/fXJWpQ==; Received: from host-92-8-62-54.as43234.net ([92.8.62.54]:57304 helo=[192.168.1.7]) by n1plcpnl0072.prod.ams1.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1dQdVX-002dS1-V2; Thu, 29 Jun 2017 10:45:36 -0700 From: "M.Lizar@OCG" Message-Id: <3D06605B-E05E-4CEE-A584-932F0D11DFE2@openconsentgroup.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DD529526-2B01-4A71-B7D4-A91568728528" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 18:45:29 +0100 In-Reply-To: Cc: Mike Jones , "id-event@ietf.org" To: William Denniss References: X-Mailer: Apple Mail (2.3273) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n1plcpnl0072.prod.ams1.secureserver.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openconsentgroup.com X-Get-Message-Sender-Via: n1plcpnl0072.prod.ams1.secureserver.net: authenticated_id: m.lizar@openconsentgroup.com X-Authenticated-Sender: n1plcpnl0072.prod.ams1.secureserver.net: m.lizar@openconsentgroup.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfJxDqTB1o7Lnye7GaN5rP9WrYpgpprqm+RCIrH6tdfhq5yfR3lUyMrVqCm1jbilDJF5zhYZ3QfHc2mIAT+8Tdl6wj4Q5GXvsgDSoTszQ8kkaObB6BDgn euRLrBfYp1WyXCyPhZMTvVYRahqaFDYx1bxjfT3rDXqw73bjGqDlJIAY8OFgRnmMp672SfpwkskMsyhr1lPluizVkmYd/H2m5zg= Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:46:40 -0000 --Apple-Mail=_DD529526-2B01-4A71-B7D4-A91568728528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1=20 Thanks for you work on this and support both these changes.=20 - Mark > On 29 Jun 2017, at 01:24, William Denniss wrote: >=20 > Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. >=20 > By making the "exp" claim that is already = = NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID = Tokens and SET uniqueness guarantee that is desired, allowing these two = types of JWTs to be used with a common issuer. This also allows "sub" to = be used for its intended purpose (as defined by RFC7519) without = modification, which other working groups that wish to profile SET have = expressed an interest to do >=20 > The benefit the community will gain from the SET standard overall is a = standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. >=20 >=20 > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: > Hi folks, >=20 > =20 >=20 > I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. >=20 > =20 >=20 > The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. >=20 > =20 >=20 > The second adds the following new section: >=20 > =20 >=20 > Requirements for SET Profiles <> > =20 > Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. > =20 > Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. > =20 > Profile Specifications MUST clearly specify the steps that a recipient = of a SET utilizing that profile MUST perform to validate that the SET is = both syntactically and semantically valid. > =20 >=20 > It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. >=20 > =20 >=20 > I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. >=20 > =20 >=20 > Best = wishes, >=20 > -- = Mike >=20 > =20 >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_DD529526-2B01-4A71-B7D4-A91568728528 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 

Thanks for you work on this and support = both these changes. 

- Mark

On 29 Jun 2017, at 01:24, William Denniss <wdenniss@google.com>= wrote:

Thank you Mike for working on = this. I'm very happy with the change regarding the "exp" claim, and = believe it is the best resolution to the "ID Token" confusion = concern.

By = making the "exp" claim that is already NOT RECOMMENDED in the current draft a MUST = NOT, we can provide the ID Tokens and SET uniqueness guarantee that is = desired, allowing these two types of JWTs to be used with a common = issuer. This also allows "sub" to be used for its intended purpose (as = defined by RFC7519) without modification, which other working groups = that wish to profile SET have expressed an interest to do

The benefit the = community will gain from the SET standard overall is a standard way to = express events that won't conflict with ID Token (no "iss" partitioning = required). With Mike's changes we achieve that, and in a way that = retains the original simplicity, extensibility and generalizability = goals of SET by not redefining any of JWT's standard claims.


On Wed, Jun 28, 2017 at 5:08 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi folks,

 

I wanted to give you a heads-up about two SET spec = updates in the current editor=E2=80=99s draft before they are = published.

 

The first solves the potential ID Token / SET = confusion problem by requiring that SETs not include a top-level = =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also be generated by = the same issuer.  Because =E2=80=9Cexp=E2=80=9D is a required ID = Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note = that this solution is already recommended in the specification.  = The editor=E2=80=99s draft update makes this solution mandatory.  = This provides a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much = discussion since.

 

The second adds the following new section:

 

Requirements for SET Profiles

 

Profile Specifications for SETs define the = syntax and semantics of SETs conforming to that SET profile and rules = for validating those SETs. The syntax defined by profiling specifications includes what claims and event payload values are used = by SETs utilizing the profile.

 

Defining the semantics of the SET contents for = SETs utilizing the profile is equally important. Possibly most important = is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used = for cryptographic operations used in the JWT representing the SET. For = instance, some profiles may define an algorithm for retrieving the SET = issuer's keys that uses the iss claim value as its = input.

 

Profile Specifications MUST clearly specify the = steps that a recipient of a SET utilizing that profile MUST perform to = validate that the SET is both syntactically and semantically valid.

 

It=E2=80=99s included to inform profile writers = about what they must do to be able to use SETs securely.  While = much of the discussion as of late has been about syntax, semantics is = equally important, and must be considered by profile writers and deployers.

 

I believe that the new section contains only = statements that are already factually accurate requirements but that = were previously unstated.  The editor=E2=80=99s draft makes these = requirements explicit.  Feedback on how to make these requirements even more clear, is of course, welcomed.

 

         =             &n= bsp;                  &nb= sp;            = ;           Best wishes,

         =             &n= bsp;                  &nb= sp;            = ;           -- Mike

 


_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_DD529526-2B01-4A71-B7D4-A91568728528-- From nobody Thu Jun 29 10:51:08 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE3E12EA54 for ; Thu, 29 Jun 2017 10:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08BW1OdzKMgS for ; Thu, 29 Jun 2017 10:51:02 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0129.outbound.protection.outlook.com [104.47.33.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8222F129B23 for ; Thu, 29 Jun 2017 10:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U574sNpiZrbqaycnmvZCqOBtNcLKpu5s8/2GDkE9KAc=; b=fKvgQ60TDB26lDZtKoDSRIYFFAKUfda4quI2wW6DYNBx4UCqZYTSIppm89UESoSSkXd0j/eFHITz6mzfWyMLw4gR3JbnpNne5zqIq2YIRMjEtvTs2fyVIwOnhluUOsNvvhsVFZWkgQnzh3isUKQfnOKCwhCaNXaTYOQyuGcK1sY= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.4; Thu, 29 Jun 2017 17:50:58 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.001; Thu, 29 Jun 2017 17:50:58 +0000 From: Mike Jones To: John Bradley , "Phil Hunt (IDM)" CC: William Denniss , "id-event@ietf.org" Thread-Topic: [Id-event] Heads-up about SET spec updates Thread-Index: AdLwa3VhxmOh1ap9Sxqj4ofmRP4gvAAApZIAAACBMYAAI5B2AAAAFXOg Date: Thu, 29 Jun 2017 17:50:58 +0000 Message-ID: References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> In-Reply-To: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-29T10:50:56.9620983-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 7:EqXmhOaZP3cbIFMz25uAmdS6WjUinaXuvs4zSTjfDikcX0MwQwVErW0AeP81OBTi+6ieOgNSaE6vJ1HKddO/HLYhAtg/Ad+wSJPUZFqWqbfGpPxqualjaEBRz6MPUBodg/FhwikqY+APpipExda679GtdF2B9rYNJ9Xx3lWJ4RONj/bbXXYRLAVI8A8L9nRhH2xAKn3sGxygT//X2GlfU38WE+p8brqwruVa1IUpW/kYANgUVyqfBSku2zDhhNNiCz8Dqy5B1rHwpwhK4Do3JmLOjBrIod5OO3Js8g3mtWD+x2w7ZnQtfoR03OMM2F7m+kQ1xFyCZd555hyRN19yqN/Cq++mfkWB1PdxeXYQ9fwiQhiCiqE2Con7V5K8ao/9P0Q9+IPKpJ9ShG5XkV/i50a6gEjhSpi2uSfLEMtl2LzL296T/sirwASDDcLsYqZ7CtovxmyuaI3l2/1Gz1yNZW1E/C/Vs2qJJJK3lOQSeq9RbHqT+xl7nsup3QZQ2B4eSXCIOful7UK4GoTjZPP4Jwq0p9P2MS5MQCwmDn9v5EVEdHgS8JVQNaHGJ2nRI3ldX4rAqx934Nv70GHfEvY+u4gL5xC2CfkdvWb6ML0wfg5zGvcVtL/9dDCdKyLHb1zGrEzsky4Zi4RRbPqne1JFRPazTJUblQSb+tfXqSLFaRaHR07pO+wds0HJd5EoYAMv5AWMIkxFCI5u3Pn/JYglMkEE/MS3t1OfpGtXaPuHbnqx+dWCCgMv+f0soMKzCUFyC3L1ou4umeSsRQLHxl5uBwkftdhCNc83SXI20bqAyXia8tVpwvdVsf9QfQPP8u7g x-ms-office365-filtering-correlation-id: a69c6e5f-e520-443d-b6dc-08d4bf17664e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603029)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0501; x-ms-traffictypediagnostic: CY4PR21MB0501: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(133145235818549)(10436049006162)(26388249023172)(236129657087228)(48057245064654)(211936372134217)(148574349560750)(21748063052155)(167848164394848); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910016)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0501; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39400400002)(39860400002)(39410400002)(39840400002)(377454003)(24454002)(7696004)(2900100001)(189998001)(86362001)(5660300001)(74316002)(236005)(9686003)(7110500001)(561944003)(77096006)(54896002)(478600001)(229853002)(53936002)(606006)(19609705001)(966005)(93886004)(72206003)(86612001)(53546010)(575784001)(14454004)(3660700001)(8936002)(4326008)(25786009)(6246003)(3280700002)(790700001)(6506006)(102836003)(6116002)(15650500001)(55016002)(6306002)(10290500003)(38730400002)(8676002)(2420400007)(33656002)(54356999)(10090500001)(2950100002)(7736002)(54906002)(99286003)(81166006)(6436002)(50986999)(5005710100001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504488CA9AEF47C8C049E90F5D20CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2017 17:50:58.5170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501 Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 17:51:06 -0000 --_000_CY4PR21MB0504488CA9AEF47C8C049E90F5D20CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBKb2huLg0KDQpUaGUgZ29vZCBuZXdzIGFib3V0IGtleSBtZXRhZGF0YSBpbiB0aGUg SUVURiBpcyB0aGF0IHdl4oCZcmUgbmVhcmx5IGRvbmUgd2l0aCBzdGFuZGFyZGl6aW5nIHRoZSBq d2tzX3VyaSBwYXR0ZXJuIGluIHRoZSBJRVRGLCBwZXIgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA2I3NlY3Rpb24tMi4gIChJdOKAmXMgY3Vy cmVudGx5IHdhaXRpbmcgZm9yIHRoZSBBRCB3cml0ZS11cCBmcm9tIEVLUi4pDQoNClBoaWwsIEkg YmVsaWV2ZSB0aGF0IGFsbCB0aGUgc3RhdGVtZW50cyBpbiB0aGUgbmV3IOKAnFJlcXVpcmVtZW50 cyBmb3IgU0VUIFByb2ZpbGVz4oCdIHNlY3Rpb24gYXJlIGRlbW9uc3RyYWJseSB0cnVlIGFuZCBh ZGQgbm8gbmV3IHJlcXVpcmVtZW50cy4gIFRoZXkgYXJlIHRoZXJlIHRvIG1ha2UgcmVxdWlyZW1l bnRzIHRoYXQgd2VyZSBhbHJlYWR5IGltcGxpY2l0IGV4cGxpY2l0LiAgUGhpbCwgaWYgeW91IGJl bGlldmUgdGhhdCBhbnkgb2YgdGhlIHNlbnRlbmNlcyBpbiB0aGUgc2VjdGlvbiBhcmUgZmFsc2Us IHBsZWFzZSBjYWxsIHRoZW0gb3V0IGV4cGxpY2l0bHkgYW5kIHNheSB3aHkgdGhleeKAmXJlIGZh bHNlLiAgSWYgb25lIG9yIG1vcmUgb2YgdGhlbSBhcmUgZmFsc2UsIEnigJlsbCBvYnZpb3VzbHkg Y2xhcmlmeSBvciByZWRhY3QgdGhvc2UsIHdoaWxlIGxlYXZpbmcgdGhlIHJlc3QgaW4gcGxhY2Ug YXMgZ3VpZGFuY2UgdG8gdXNlcnMgb2YgdGhlIHNwZWMuDQoNCknigJlsbCBwb2ludCBvdXQgdGhh dCBldmVuIGlmIGEgcHJvZmlsZSBkZWNpZGVkIHRvIGRlbGVnYXRlIGl0cyBrZXkgbWFuYWdlbWVu dCB0byBhIHRyYW5zcG9ydCwgYXMgeW914oCZcmUgYWR2b2NhdGluZywgUGhpbCwgdGhlIHByb2Zp bGUgd291bGQgc3RpbGwgbmVlZCB0byBleHBsaWNpdGx5IHNheSB0aGF0LiAgSXQgd291bGRu4oCZ dCBiZSBhIGNvbXBsZXRlIG9yIHVzYWJsZSBwcm9maWxlIGlmIGl0IGRpZG7igJl0IGRlZmluZSBo b3cgdG8gcmV0cmlldmUgdGhlIGtleXMgdXNlZCB0byB2YWxpZGF0ZSB0aGUgSldULiAgU28geW91 ciBwcm9wb3NhbCBpcyBvbmUgd2F5IG9mIGEgcHJvZmlsZSBzYXRpc2Z5aW5nIHRoZSByZXF1aXJl bWVudCDigJxQb3NzaWJseSBtb3N0IGltcG9ydGFudCBpcyBkZWZpbmluZyB0aGUgcHJvY2VkdXJl cyB1c2VkIHRvIHZhbGlkYXRlIHRoZSBTRVQgaXNzdWVyIGFuZCB0byBvYnRhaW4gdGhlIGtleXMg Y29udHJvbGxlZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1c2VkIGZvciBjcnlwdG9ncmFwaGlj IG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2VudGluZyB0aGUgU0VULuKAnSAgR2l2 ZW4gdGhhdCB5b3VyIHByb3Bvc2FsIGlzIGEgd2F5IHRvIHNhdGlzZnkgdGhpcyByZXF1aXJlbWVu dCwgSSBkb27igJl0IHNlZSBhbnkgZ3JvdW5kcyBmb3IgeW91IHRvIG9wcG9zZSBpdC4gIEluIGZh Y3QsIEkgYmVsaWV2ZSBpdCBhcmd1ZXMgdGhhdCB5b3Ugc2hvdWxkIHN1cHBvcnQgaXQuDQoNClNh eWluZyBub3RoaW5nIGFib3V0IHRoZSBzZW1hbnRpYyByZXF1aXJlbWVudHMgaXMgZG9pbmcgbm8g b25lIGFueSBmYXZvcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWxsLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBUaHVy c2RheSwgSnVuZSAyOSwgMjAxNyAxMDozNyBBTQ0KVG86IFBoaWwgSHVudCAoSURNKSA8cGhpbC5o dW50QG9yYWNsZS5jb20+DQpDYzogV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29t PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgaWQtZXZlbnRAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIEhlYWRzLXVwIGFib3V0IFNFVCBzcGVjIHVw ZGF0ZXMNCg0KSSBhZ3JlZSBvbiBleHAuDQoNCkkgdGhpbmsgZGVmaW5pbmcgdHJ1c3QgcmVsYXRp b25zaGlwcyBzaG91bGQgYmUgaW4gdGhlIHByb2ZpbGVzIGFzIHRoZXkgbWF5IGJlIHF1aXRlIGRp ZmZlcmVudC4NCg0KVGhhdCBpcyB3aHkgbWl4aW5nIGV2ZW50cyBpbiB0aGUgc2FtZSBtZXNzYWdl IHdpbGwgYmUgYSBwcm9ibGVtLiAgSSB0aG91Z2h0IHdlIGFncmVlZCBvbiB0aGF0Lg0KDQpUcnlp bmcgdG8gZGVmaW5lIGEgZml4ZWQgdHJ1c3QgcmVsYXRpb25zaGlwIGZvciB0aGUgdHJhbnNwb3J0 IGlzIGxpa2VseSBnb2luZyB0byBjYXVzZSBwZW9wbGUgdG8gcm9sbCB0aGVyZSBvd24uDQoNCkV2 ZW4gaW4gQ29ubmVjdCBmb3Igc3BlY2lmaWMgdmVydGljYWxzIGxpa2UgZmluYW5jZSB3ZSBzZWUg ZGlmZnJlbmNlcyBpbiByZWdpc3RyYXRpb24gZXRjIHRvIHJlZmxlY3QgdGhlIG5lZWQgdG8gYWNj b21tb2RhdGUgZUlEUyBhbmQgb3RoZXIgcmVndWxhdGlvbnMuDQoNCk9uZSBzaXplIGZpdHMgYWxs IGlzIGdyZWF0IGlmIHlvdSBhcmUgdGhlIG9uZSBzaXplLg0KDQpJIGRvIHRoaW5rIHdlIHNob3Vs ZCBlbmNvdXJhZ2UgcGVvcGxlIHRvIHVzZSBKV0tTIFVSSSBkaXNjb3ZlcnMgZnJvbSBpc3N1ZXIg bWV0YS1kYXRhIGJhc2VkIG9uIHRoZSBpc3N1ZXJzIHdlbGwta25vd24gYXMgYSBwYXR0ZXJuIHRo YXQgaGFzIHByb3ZlbiB0byBiZSByZXBlYXRhYmxlLg0KDQpJdCB3b3VsZCBiZSBuaWNlIGlmIHdl IGhhZCB0aG9zZSBzcGVjcyBkb25lIGluIHRoZSBJRVRGOikNCg0KSm9obiBCLg0KDQoNCk9uIEp1 biAyOCwgMjAxNywgYXQgODozOCBQTSwgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xl LmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSSBhZ3JlZSBvbiB0 aGUgZXhwIHBhcnQuDQoNClJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcnQuIEkgd291bGQgbGlrZSB0 byBzZWUgbW9yZSBkaXNjdXNzaW9uLg0KDQpGb3IgZXhhbXBsZSwgaW4gdGhlIHRoZSB1c2UgY2Fz ZXMsIHRoZXJlIG1heSBiZSBjb21wYXRpYmlsaXR5IGlzc3VlcyBpZiBkaWZmZXJlbnQgc2V0IHBy b2ZpbGVzIGNhbm5vdCBiZSBzZW50IG92ZXIgdGhlIHNhbWUgc3RyZWFtLg0KDQpTdWNoIHByb2Zp bGVzIHNob3VsZCBhdm9pZCB0aGluZ3MgbGlrZSByZXF1aXJpbmcgc2lnbmluZyBhbmQgZW5jcnlw dGlvbiB3aXRob3V0IGNvbnNpZGVyYXRpb24gcmVnYXJkaW5nIGhvdyB0aGV5IGFyZSB0cmFuc2Zl cnJlZC4gIEFsc28ga2V5IG1hbmFnZW1lbnQgbWlnaHQgYmUgYmV0dGVyIHRpZWQgdXAgaW4gaG93 IHRoZSBzdHJlYW1zIGFyZSBtYW5hZ2VzIGJlY2F1c2UgdGhlIG5ldHdvcmsgcmVsYXRpb25zaGlw IG1heSBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyByYXRoZXIgdGhhbiB0aGUgZGF0YS4NCg0KTXkg aW5pdGlhbCByZWFjdGlvbiBpcywgdGhlIHByb2ZpbGVzIHNob3VsZCBzdGljayB0byB0aGUgZGF0 YSBhbmQgdmFsaWQgaW50ZXJwcmV0YXRpb24uDQoNCklmIHRoZSBncm91cCBhZ3JlZXMgSSB3aWxs IG1lcmdlIHRoZSBleHAgYW5kIHBvc3Qgb3ZlciB0aGUgd2Vla2VuZC4NCg0KSSBjYW4gbWVyZ2Ug dGhlIHNlY29uZCBwYXJ0IGlmIHRoZXJlIGlzIGEgc3Ryb25nIGFncmVlbWVudCB0byBkbyBzby4N Cg0KVGhhbmtzIQ0KDQpQaGlsDQoNCk9uIEp1biAyOCwgMjAxNywgYXQgNToyNCBQTSwgV2lsbGlh bSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29t Pj4gd3JvdGU6DQpUaGFuayB5b3UgTWlrZSBmb3Igd29ya2luZyBvbiB0aGlzLiBJJ20gdmVyeSBo YXBweSB3aXRoIHRoZSBjaGFuZ2UgcmVnYXJkaW5nIHRoZSAiZXhwIiBjbGFpbSwgYW5kIGJlbGll dmUgaXQgaXMgdGhlIGJlc3QgcmVzb2x1dGlvbiB0byB0aGUgIklEIFRva2VuIiBjb25mdXNpb24g Y29uY2Vybi4NCg0KQnkgbWFraW5nIHRoZSAiZXhwIiBjbGFpbSB0aGF0IGlzIGFscmVhZHk8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRHNlY2V2ZW50LTJEdG9rZW4tMkQwMS0yM3NlY3Rp b24tMkQyLjEmZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPV9Y Rjk5NHpWbjFfQWVTLUN6U3RxT1FhVlFwc2RqanZmQnkzNVMwbzd0SDAmcz01TDlxcUhfZXZrbFgt SGpERjhLa1oyZTViTmE2ZlpjM2tKSVhMMnFmVVdzJmU9PiBOT1QgUkVDT01NRU5ERUQgaW4gdGhl IGN1cnJlbnQgZHJhZnQgYSBNVVNUIE5PVCwgd2UgY2FuIHByb3ZpZGUgdGhlIElEIFRva2VucyBh bmQgU0VUIHVuaXF1ZW5lc3MgZ3VhcmFudGVlIHRoYXQgaXMgZGVzaXJlZCwgYWxsb3dpbmcgdGhl c2UgdHdvIHR5cGVzIG9mIEpXVHMgdG8gYmUgdXNlZCB3aXRoIGEgY29tbW9uIGlzc3Vlci4gVGhp cyBhbHNvIGFsbG93cyAic3ViIiB0byBiZSB1c2VkIGZvciBpdHMgaW50ZW5kZWQgcHVycG9zZSAo YXMgZGVmaW5lZCBieSBSRkM3NTE5KSB3aXRob3V0IG1vZGlmaWNhdGlvbiwgd2hpY2ggb3RoZXIg d29ya2luZyBncm91cHMgdGhhdCB3aXNoIHRvIHByb2ZpbGUgU0VUIGhhdmUgZXhwcmVzc2VkIGFu IGludGVyZXN0IHRvIGRvDQoNClRoZSBiZW5lZml0IHRoZSBjb21tdW5pdHkgd2lsbCBnYWluIGZy b20gdGhlIFNFVCBzdGFuZGFyZCBvdmVyYWxsIGlzIGEgc3RhbmRhcmQgd2F5IHRvIGV4cHJlc3Mg ZXZlbnRzIHRoYXQgd29uJ3QgY29uZmxpY3Qgd2l0aCBJRCBUb2tlbiAobm8gImlzcyIgcGFydGl0 aW9uaW5nIHJlcXVpcmVkKS4gV2l0aCBNaWtlJ3MgY2hhbmdlcyB3ZSBhY2hpZXZlIHRoYXQsIGFu ZCBpbiBhIHdheSB0aGF0IHJldGFpbnMgdGhlIG9yaWdpbmFsIHNpbXBsaWNpdHksIGV4dGVuc2li aWxpdHkgYW5kIGdlbmVyYWxpemFiaWxpdHkgZ29hbHMgb2YgU0VUIGJ5IG5vdCByZWRlZmluaW5n IGFueSBvZiBKV1QncyBzdGFuZGFyZCBjbGFpbXMuDQoNCg0KT24gV2VkLCBKdW4gMjgsIDIwMTcg YXQgNTowOCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkhpIGZvbGtzLA0KDQpJIHdh bnRlZCB0byBnaXZlIHlvdSBhIGhlYWRzLXVwIGFib3V0IHR3byBTRVQgc3BlYyB1cGRhdGVzIGlu IHRoZSBjdXJyZW50IGVkaXRvcuKAmXMgZHJhZnQgYmVmb3JlIHRoZXkgYXJlIHB1Ymxpc2hlZC4N Cg0KVGhlIGZpcnN0IHNvbHZlcyB0aGUgcG90ZW50aWFsIElEIFRva2VuIC8gU0VUIGNvbmZ1c2lv biBwcm9ibGVtIGJ5IHJlcXVpcmluZyB0aGF0IFNFVHMgbm90IGluY2x1ZGUgYSB0b3AtbGV2ZWwg 4oCcZXhw4oCdIGNsYWltIHdoZW4gSUQgVG9rZW5zIGNvdWxkIGFsc28gYmUgZ2VuZXJhdGVkIGJ5 IHRoZSBzYW1lIGlzc3Vlci4gIEJlY2F1c2Ug4oCcZXhw4oCdIGlzIGEgcmVxdWlyZWQgSUQgVG9r ZW4gY2xhaW0sIFNFVHMgd291bGQgdGhlcmVmb3JlIGJlIHJlamVjdGVkIGJ5IGV4aXN0aW5nIElE IFRva2VuIHZhbGlkYXRpb24gY29kZS4gIE5vdGUgdGhhdCB0aGlzIHNvbHV0aW9uIGlzIGFscmVh ZHkgcmVjb21tZW5kZWQgaW4gdGhlIHNwZWNpZmljYXRpb24uICBUaGUgZWRpdG9y4oCZcyBkcmFm dCB1cGRhdGUgbWFrZXMgdGhpcyBzb2x1dGlvbiBtYW5kYXRvcnkuICBUaGlzIHByb3ZpZGVzIGEg c2ltcGxlIGFuZCBkdXJhYmxlIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIHdlIGFncmVlZCB0byBz b2x2ZSBhdCBJRVRGIDk4IGluIENoaWNhZ28gYW5kIHRoYXQgaGFzIGJlZW4gdGhlIHN1YmplY3Qg b2YgbXVjaCBkaXNjdXNzaW9uIHNpbmNlLg0KDQpUaGUgc2Vjb25kIGFkZHMgdGhlIGZvbGxvd2lu ZyBuZXcgc2VjdGlvbjoNCg0KUmVxdWlyZW1lbnRzIGZvciBTRVQgUHJvZmlsZXMNCg0KUHJvZmls ZSBTcGVjaWZpY2F0aW9ucyBmb3IgU0VUcyBkZWZpbmUgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNz IG9mIFNFVHMgY29uZm9ybWluZyB0byB0aGF0IFNFVCBwcm9maWxlIGFuZCBydWxlcyBmb3IgdmFs aWRhdGluZyB0aG9zZSBTRVRzLiBUaGUgc3ludGF4IGRlZmluZWQgYnkgcHJvZmlsaW5nIHNwZWNp ZmljYXRpb25zIGluY2x1ZGVzIHdoYXQgY2xhaW1zIGFuZCBldmVudCBwYXlsb2FkIHZhbHVlcyBh cmUgdXNlZCBieSBTRVRzIHV0aWxpemluZyB0aGUgcHJvZmlsZS4NCg0KRGVmaW5pbmcgdGhlIHNl bWFudGljcyBvZiB0aGUgU0VUIGNvbnRlbnRzIGZvciBTRVRzIHV0aWxpemluZyB0aGUgcHJvZmls ZSBpcyBlcXVhbGx5IGltcG9ydGFudC4gUG9zc2libHkgbW9zdCBpbXBvcnRhbnQgaXMgZGVmaW5p bmcgdGhlIHByb2NlZHVyZXMgdXNlZCB0byB2YWxpZGF0ZSB0aGUgU0VUIGlzc3VlciBhbmQgdG8g b2J0YWluIHRoZSBrZXlzIGNvbnRyb2xsZWQgYnkgdGhlIGlzc3VlciB0aGF0IHdlcmUgdXNlZCBm b3IgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zIHVzZWQgaW4gdGhlIEpXVCByZXByZXNlbnRpbmcg dGhlIFNFVC4gRm9yIGluc3RhbmNlLCBzb21lIHByb2ZpbGVzIG1heSBkZWZpbmUgYW4gYWxnb3Jp dGhtIGZvciByZXRyaWV2aW5nIHRoZSBTRVQgaXNzdWVyJ3Mga2V5cyB0aGF0IHVzZXMgdGhlIGlz cyBjbGFpbSB2YWx1ZSBhcyBpdHMgaW5wdXQuDQoNClByb2ZpbGUgU3BlY2lmaWNhdGlvbnMgTVVT VCBjbGVhcmx5IHNwZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYSByZWNpcGllbnQgb2YgYSBTRVQgdXRp bGl6aW5nIHRoYXQgcHJvZmlsZSBNVVNUIHBlcmZvcm0gdG8gdmFsaWRhdGUgdGhhdCB0aGUgU0VU IGlzIGJvdGggc3ludGFjdGljYWxseSBhbmQgc2VtYW50aWNhbGx5IHZhbGlkLg0KDQpJdOKAmXMg aW5jbHVkZWQgdG8gaW5mb3JtIHByb2ZpbGUgd3JpdGVycyBhYm91dCB3aGF0IHRoZXkgbXVzdCBk byB0byBiZSBhYmxlIHRvIHVzZSBTRVRzIHNlY3VyZWx5LiAgV2hpbGUgbXVjaCBvZiB0aGUgZGlz Y3Vzc2lvbiBhcyBvZiBsYXRlIGhhcyBiZWVuIGFib3V0IHN5bnRheCwgc2VtYW50aWNzIGlzIGVx dWFsbHkgaW1wb3J0YW50LCBhbmQgbXVzdCBiZSBjb25zaWRlcmVkIGJ5IHByb2ZpbGUgd3JpdGVy cyBhbmQgZGVwbG95ZXJzLg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgbmV3IHNlY3Rpb24gY29udGFp bnMgb25seSBzdGF0ZW1lbnRzIHRoYXQgYXJlIGFscmVhZHkgZmFjdHVhbGx5IGFjY3VyYXRlIHJl cXVpcmVtZW50cyBidXQgdGhhdCB3ZXJlIHByZXZpb3VzbHkgdW5zdGF0ZWQuICBUaGUgZWRpdG9y 4oCZcyBkcmFmdCBtYWtlcyB0aGVzZSByZXF1aXJlbWVudHMgZXhwbGljaXQuICBGZWVkYmFjayBv biBob3cgdG8gbWFrZSB0aGVzZSByZXF1aXJlbWVudHMgZXZlbiBtb3JlIGNsZWFyLCBpcyBvZiBj b3Vyc2UsIHdlbGNvbWVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1l dmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRm Lm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09X1hGOTk0elZuMV9BZVMtQ3pTdHFPUWFW UXBzZGpqdmZCeTM1UzBvN3RIMCZzPTNzMUdDYy0zZzJLVV9wTjZIdldWSGdXQkpYczZPR1BZOEst bkZhcVV4S1EmZT0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1l dmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQNCg0K --_000_CY4PR21MB0504488CA9AEF47C8C049E90F5D20CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoYW5rcywg Sm9obi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoZSBnb29kIG5ld3Mg YWJvdXQga2V5IG1ldGFkYXRhIGluIHRoZSBJRVRGIGlzIHRoYXQgd2XigJlyZSBuZWFybHkgZG9u ZSB3aXRoIHN0YW5kYXJkaXppbmcgdGhlIGp3a3NfdXJpIHBhdHRlcm4gaW4gdGhlIElFVEYsIHBl cg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt ZGlzY292ZXJ5LTA2I3NlY3Rpb24tMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtZGlzY292ZXJ5LTA2I3NlY3Rpb24tMjwvYT4uJm5ic3A7IChJdOKAmXMgY3Vy cmVudGx5IHdhaXRpbmcgZm9yIHRoZSBBRCB3cml0ZS11cCBmcm9tIEVLUi4pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QaGlsLCBJIGJlbGlldmUgdGhhdCBhbGwgdGhlIHN0 YXRlbWVudHMgaW4gdGhlIG5ldyDigJxSZXF1aXJlbWVudHMgZm9yIFNFVCBQcm9maWxlc+KAnSBz ZWN0aW9uIGFyZSBkZW1vbnN0cmFibHkgdHJ1ZSBhbmQgYWRkIG5vIG5ldyByZXF1aXJlbWVudHMu Jm5ic3A7IFRoZXkgYXJlIHRoZXJlIHRvIG1ha2UgcmVxdWlyZW1lbnRzIHRoYXQgd2VyZSBhbHJl YWR5IGltcGxpY2l0IGV4cGxpY2l0LiZuYnNwOw0KIFBoaWwsIGlmIHlvdSBiZWxpZXZlIHRoYXQg YW55IG9mIHRoZSBzZW50ZW5jZXMgaW4gdGhlIHNlY3Rpb24gYXJlIGZhbHNlLCBwbGVhc2UgY2Fs bCB0aGVtIG91dCBleHBsaWNpdGx5IGFuZCBzYXkgd2h5IHRoZXnigJlyZSBmYWxzZS4mbmJzcDsg SWYgb25lIG9yIG1vcmUgb2YgdGhlbSBhcmUgZmFsc2UsIEnigJlsbCBvYnZpb3VzbHkgY2xhcmlm eSBvciByZWRhY3QgdGhvc2UsIHdoaWxlIGxlYXZpbmcgdGhlIHJlc3QgaW4gcGxhY2UgYXMgZ3Vp ZGFuY2UgdG8gdXNlcnMNCiBvZiB0aGUgc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPknigJlsbCBwb2ludCBvdXQgdGhhdCBldmVuIGlmIGEgcHJvZmlsZSBkZWNpZGVk IHRvIGRlbGVnYXRlIGl0cyBrZXkgbWFuYWdlbWVudCB0byBhIHRyYW5zcG9ydCwgYXMgeW914oCZ cmUgYWR2b2NhdGluZywgUGhpbCwgdGhlIHByb2ZpbGUgd291bGQgc3RpbGwgbmVlZCB0byBleHBs aWNpdGx5IHNheSB0aGF0LiAmbmJzcDtJdCB3b3VsZG7igJl0IGJlIGEgY29tcGxldGUgb3IgdXNh YmxlDQogcHJvZmlsZSBpZiBpdCBkaWRu4oCZdCBkZWZpbmUgaG93IHRvIHJldHJpZXZlIHRoZSBr ZXlzIHVzZWQgdG8gdmFsaWRhdGUgdGhlIEpXVC4mbmJzcDsgU28geW91ciBwcm9wb3NhbCBpcyBv bmUgd2F5IG9mIGEgcHJvZmlsZSBzYXRpc2Z5aW5nIHRoZSByZXF1aXJlbWVudCDigJw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+UG9zc2libHkgbW9zdCBpbXBvcnRhbnQgaXMNCiBk ZWZpbmluZyB0aGUgcHJvY2VkdXJlcyB1c2VkIHRvIHZhbGlkYXRlIHRoZSBTRVQgaXNzdWVyIGFu ZCB0byBvYnRhaW4gdGhlIGtleXMgY29udHJvbGxlZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1 c2VkIGZvciBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2Vu dGluZyB0aGUgU0VULjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+4oCdJm5ic3A7 IEdpdmVuIHRoYXQgeW91ciBwcm9wb3NhbCBpcyBhIHdheQ0KIHRvIHNhdGlzZnkgdGhpcyByZXF1 aXJlbWVudCwgSSBkb27igJl0IHNlZSBhbnkgZ3JvdW5kcyBmb3IgeW91IHRvIG9wcG9zZSBpdC4m bmJzcDsgSW4gZmFjdCwgSSBiZWxpZXZlIGl0IGFyZ3VlcyB0aGF0IHlvdSBzaG91bGQgc3VwcG9y dCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlNheWluZyBub3RoaW5n IGFib3V0IHRoZSBzZW1hbnRpYyByZXF1aXJlbWVudHMgaXMgZG9pbmcgbm8gb25lIGFueSBmYXZv cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKb2huIEJyYWRsZXkgW21haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDI5LCAy MDE3IDEwOjM3IEFNPGJyPg0KPGI+VG86PC9iPiBQaGlsIEh1bnQgKElETSkgJmx0O3BoaWwuaHVu dEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gV2lsbGlhbSBEZW5uaXNzICZsdDt3ZGVu bmlzc0Bnb29nbGUuY29tJmd0OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tJmd0OzsgaWQtZXZlbnRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJ ZC1ldmVudF0gSGVhZHMtdXAgYWJvdXQgU0VUIHNwZWMgdXBkYXRlczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSBvbiBleHAuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGRlZmluaW5nIHRydXN0IHJlbGF0 aW9uc2hpcHMgc2hvdWxkIGJlIGluIHRoZSBwcm9maWxlcyBhcyB0aGV5IG1heSBiZSBxdWl0ZSBk aWZmZXJlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYXQgaXMgd2h5IG1peGluZyBldmVudHMgaW4gdGhlIHNhbWUgbWVzc2FnZSB3aWxs IGJlIGEgcHJvYmxlbS4gJm5ic3A7SSB0aG91Z2h0IHdlIGFncmVlZCBvbiB0aGF0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcnlpbmcgdG8g ZGVmaW5lIGEgZml4ZWQgdHJ1c3QgcmVsYXRpb25zaGlwIGZvciB0aGUgdHJhbnNwb3J0IGlzIGxp a2VseSBnb2luZyB0byBjYXVzZSBwZW9wbGUgdG8gcm9sbCB0aGVyZSBvd24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4gaW4gQ29ubmVj dCBmb3Igc3BlY2lmaWMgdmVydGljYWxzIGxpa2UgZmluYW5jZSB3ZSBzZWUgZGlmZnJlbmNlcyBp biByZWdpc3RyYXRpb24gZXRjIHRvIHJlZmxlY3QgdGhlIG5lZWQgdG8gYWNjb21tb2RhdGUgZUlE UyBhbmQgb3RoZXIgcmVndWxhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBzaXplIGZpdHMgYWxsIGlzIGdyZWF0IGlmIHlvdSBh cmUgdGhlIG9uZSBzaXplLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyB0aGluayB3ZSBzaG91bGQgZW5jb3VyYWdlIHBlb3Bs ZSB0byB1c2UgSldLUyBVUkkgZGlzY292ZXJzIGZyb20gaXNzdWVyIG1ldGEtZGF0YSBiYXNlZCBv biB0aGUgaXNzdWVycyB3ZWxsLWtub3duIGFzIGEgcGF0dGVybiB0aGF0IGhhcyBwcm92ZW4gdG8g YmUgcmVwZWF0YWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgYmUgbmljZSBpZiB3ZSBoYWQgdGhvc2Ugc3BlY3Mg ZG9uZSBpbiB0aGUgSUVURjopPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDI4LCAyMDE3LCBhdCA4OjM4IFBNLCBQaGls IEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhp bC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgb24gdGhlIGV4 cCBwYXJ0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPlJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcnQuIEkgd291bGQgbGlrZSB0byBzZWUgbW9yZSBk aXNjdXNzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkZvciBleGFtcGxlLCBpbiB0aGUgdGhlIHVzZSBjYXNlcywgdGhlcmUgbWF5IGJlIGNv bXBhdGliaWxpdHkgaXNzdWVzIGlmIGRpZmZlcmVudCBzZXQgcHJvZmlsZXMgY2Fubm90IGJlIHNl bnQgb3ZlciB0aGUgc2FtZSBzdHJlYW0uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+U3VjaCBwcm9maWxlcyBzaG91bGQgYXZvaWQgdGhpbmdzIGxp a2UgcmVxdWlyaW5nIHNpZ25pbmcgYW5kIGVuY3J5cHRpb24gd2l0aG91dCBjb25zaWRlcmF0aW9u IHJlZ2FyZGluZyBob3cgdGhleSBhcmUgdHJhbnNmZXJyZWQuICZuYnNwO0Fsc28ga2V5IG1hbmFn ZW1lbnQgbWlnaHQgYmUgYmV0dGVyIHRpZWQNCiB1cCBpbiBob3cgdGhlIHN0cmVhbXMgYXJlIG1h bmFnZXMgYmVjYXVzZSB0aGUgbmV0d29yayByZWxhdGlvbnNoaXAgbWF5IGRlZmluZSB0aGUgcmVx dWlyZW1lbnRzIHJhdGhlciB0aGFuIHRoZSBkYXRhLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGluaXRpYWwgcmVhY3Rpb24gaXMsIHRoZSBw cm9maWxlcyBzaG91bGQgc3RpY2sgdG8gdGhlIGRhdGEgYW5kIHZhbGlkIGludGVycHJldGF0aW9u LiZuYnNwOzxicj4NCjxicj4NCklmIHRoZSBncm91cCBhZ3JlZXMgSSB3aWxsIG1lcmdlIHRoZSBl eHAgYW5kIHBvc3Qgb3ZlciB0aGUgd2Vla2VuZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGNhbiBtZXJnZSB0aGUgc2Vjb25kIHBhcnQgaWYg dGhlcmUgaXMgYSBzdHJvbmcgYWdyZWVtZW50IHRvIGRvIHNvLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48YnI+DQpQaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48YnI+DQpPbiBKdW4gMjgsIDIwMTcsIGF0IDU6MjQgUE0sIFdpbGxpYW0gRGVubmlz cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iPndkZW5uaXNzQGdvb2ds ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFuayB5b3UgTWlrZSBmb3Igd29y a2luZyBvbiB0aGlzLiBJJ20gdmVyeSBoYXBweSB3aXRoIHRoZSBjaGFuZ2UgcmVnYXJkaW5nIHRo ZSAmcXVvdDtleHAmcXVvdDsgY2xhaW0sIGFuZCBiZWxpZXZlIGl0IGlzIHRoZSBiZXN0IHJlc29s dXRpb24gdG8gdGhlICZxdW90O0lEIFRva2VuJnF1b3Q7IGNvbmZ1c2lvbiBjb25jZXJuLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkJ5IG1ha2luZyB0aGUg JnF1b3Q7ZXhwJnF1b3Q7IGNsYWltIHRoYXQgaXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0 Zi0yRHNlY2V2ZW50LTJEdG9rZW4tMkQwMS0yM3NlY3Rpb24tMkQyLjEmYW1wO2Q9RHdNRmFRJmFt cDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJt NWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1fWEY5OTR6Vm4x X0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTVMOXFxSF9ldmtsWC1IakRG OEtrWjJlNWJOYTZmWmMza0pJWEwycWZVV3MmYW1wO2U9Ij5hbHJlYWR5PC9hPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OT1QNCiBSRUNPTU1FTkRFRCBp biB0aGUgY3VycmVudCBkcmFmdCBhIE1VU1QgTk9ULCB3ZSBjYW4gcHJvdmlkZSB0aGUgSUQgVG9r ZW5zIGFuZCBTRVQgdW5pcXVlbmVzcyBndWFyYW50ZWUgdGhhdCBpcyBkZXNpcmVkLCBhbGxvd2lu ZyB0aGVzZSB0d28gdHlwZXMgb2YgSldUcyB0byBiZSB1c2VkIHdpdGggYSBjb21tb24gaXNzdWVy LiBUaGlzIGFsc28gYWxsb3dzICZxdW90O3N1YiZxdW90OyB0byBiZSB1c2VkIGZvciBpdHMgaW50 ZW5kZWQgcHVycG9zZSAoYXMgZGVmaW5lZA0KIGJ5IFJGQzc1MTkpIHdpdGhvdXQgbW9kaWZpY2F0 aW9uLCB3aGljaCBvdGhlciB3b3JraW5nIGdyb3VwcyB0aGF0IHdpc2ggdG8gcHJvZmlsZSBTRVQg aGF2ZSBleHByZXNzZWQgYW4gaW50ZXJlc3QgdG8gZG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgYmVuZWZpdCB0aGUgY29tbXVuaXR5IHdpbGwgZ2Fp biBmcm9tIHRoZSBTRVQgc3RhbmRhcmQgb3ZlcmFsbCBpcyBhIHN0YW5kYXJkIHdheSB0byBleHBy ZXNzIGV2ZW50cyB0aGF0IHdvbid0IGNvbmZsaWN0IHdpdGggSUQgVG9rZW4gKG5vICZxdW90O2lz cyZxdW90OyBwYXJ0aXRpb25pbmcgcmVxdWlyZWQpLiBXaXRoDQogTWlrZSdzIGNoYW5nZXMgd2Ug YWNoaWV2ZSB0aGF0LCBhbmQgaW4gYSB3YXkgdGhhdCByZXRhaW5zIHRoZSBvcmlnaW5hbCBzaW1w bGljaXR5LCBleHRlbnNpYmlsaXR5IGFuZCBnZW5lcmFsaXphYmlsaXR5IGdvYWxzIG9mIFNFVCBi eSBub3QgcmVkZWZpbmluZyBhbnkgb2YgSldUJ3Mgc3RhbmRhcmQgY2xhaW1zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIFdlZCwgSnVuIDI4LCAyMDE3IGF0IDU6MDggUE0sIE1pa2UgSm9uZXM8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHdhbnRlZCB0byBnaXZlIHlvdSBh IGhlYWRzLXVwIGFib3V0IHR3byBTRVQgc3BlYyB1cGRhdGVzIGluIHRoZSBjdXJyZW50IGVkaXRv cuKAmXMgZHJhZnQgYmVmb3JlIHRoZXkgYXJlIHB1Ymxpc2hlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+VGhlIGZpcnN0IHNvbHZlcyB0aGUgcG90ZW50aWFsIElEIFRva2VuIC8gU0VUIGNvbmZ1c2lv biBwcm9ibGVtIGJ5IHJlcXVpcmluZyB0aGF0IFNFVHMgbm90IGluY2x1ZGUgYSB0b3AtbGV2ZWwg 4oCcZXhw4oCdDQogY2xhaW0gd2hlbiBJRCBUb2tlbnMgY291bGQgYWxzbyBiZSBnZW5lcmF0ZWQg YnkgdGhlIHNhbWUgaXNzdWVyLiZuYnNwOyBCZWNhdXNlIOKAnGV4cOKAnSBpcyBhIHJlcXVpcmVk IElEIFRva2VuIGNsYWltLCBTRVRzIHdvdWxkIHRoZXJlZm9yZSBiZSByZWplY3RlZCBieSBleGlz dGluZyBJRCBUb2tlbiB2YWxpZGF0aW9uIGNvZGUuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIHNvbHV0 aW9uIGlzIGFscmVhZHkgcmVjb21tZW5kZWQgaW4gdGhlIHNwZWNpZmljYXRpb24uJm5ic3A7IFRo ZQ0KIGVkaXRvcuKAmXMgZHJhZnQgdXBkYXRlIG1ha2VzIHRoaXMgc29sdXRpb24gbWFuZGF0b3J5 LiZuYnNwOyBUaGlzIHByb3ZpZGVzIGEgc2ltcGxlIGFuZCBkdXJhYmxlIHNvbHV0aW9uIHRvIHRo ZSBwcm9ibGVtIHdlIGFncmVlZCB0byBzb2x2ZSBhdCBJRVRGIDk4IGluIENoaWNhZ28gYW5kIHRo YXQgaGFzIGJlZW4gdGhlIHN1YmplY3Qgb2YgbXVjaCBkaXNjdXNzaW9uIHNpbmNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgc2Vjb25kIGFkZHMgdGhlIGZvbGxvd2luZyBuZXcgc2VjdGlvbjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdp bi1sZWZ0OjI0LjBwdCI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5SZXF1aXJlbWVudHMg Zm9yIFNFVCBQcm9maWxlczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmIj5Qcm9maWxlIFNwZWNpZmljYXRpb25zIGZvciBTRVRzIGRlZmlu ZSB0aGUgc3ludGF4IGFuZCBzZW1hbnRpY3Mgb2YgU0VUcyBjb25mb3JtaW5nIHRvIHRoYXQgU0VU IHByb2ZpbGUgYW5kIHJ1bGVzIGZvciB2YWxpZGF0aW5nIHRob3NlIFNFVHMuIFRoZSBzeW50YXgg ZGVmaW5lZCBieSBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbnMNCiBpbmNsdWRlcyB3aGF0IGNsYWlt cyBhbmQgZXZlbnQgcGF5bG9hZCB2YWx1ZXMgYXJlIHVzZWQgYnkgU0VUcyB1dGlsaXppbmcgdGhl IHByb2ZpbGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWxlZnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPkRlZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFNFVCBjb250ZW50cyBm b3IgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUgaXMgZXF1YWxseSBpbXBvcnRhbnQuIFBvc3Np Ymx5IG1vc3QgaW1wb3J0YW50IGlzIGRlZmluaW5nIHRoZSBwcm9jZWR1cmVzIHVzZWQgdG8gdmFs aWRhdGUgdGhlIFNFVCBpc3N1ZXIgYW5kDQogdG8gb2J0YWluIHRoZSBrZXlzIGNvbnRyb2xsZWQg YnkgdGhlIGlzc3VlciB0aGF0IHdlcmUgdXNlZCBmb3IgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25z IHVzZWQgaW4gdGhlIEpXVCByZXByZXNlbnRpbmcgdGhlIFNFVC4gRm9yIGluc3RhbmNlLCBzb21l IHByb2ZpbGVzIG1heSBkZWZpbmUgYW4gYWxnb3JpdGhtIGZvciByZXRyaWV2aW5nIHRoZSBTRVQg aXNzdWVyJ3Mga2V5cyB0aGF0IHVzZXMgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmlzczwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmNsYWlt DQogdmFsdWUgYXMgaXRzIGlucHV0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1sZWZ0OjI0LjBwdCI+DQo8 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Qcm9maWxlIFNwZWNpZmljYXRpb25zIE1VU1QgY2xl YXJseSBzcGVjaWZ5IHRoZSBzdGVwcyB0aGF0IGEgcmVjaXBpZW50IG9mIGEgU0VUIHV0aWxpemlu ZyB0aGF0IHByb2ZpbGUgTVVTVCBwZXJmb3JtIHRvIHZhbGlkYXRlIHRoYXQgdGhlIFNFVCBpcyBi b3RoIHN5bnRhY3RpY2FsbHkgYW5kIHNlbWFudGljYWxseSB2YWxpZC48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdOKAmXMgaW5jbHVkZWQgdG8gaW5mb3JtIHByb2ZpbGUg d3JpdGVycyBhYm91dCB3aGF0IHRoZXkgbXVzdCBkbyB0byBiZSBhYmxlIHRvIHVzZSBTRVRzIHNl Y3VyZWx5LiZuYnNwOyBXaGlsZSBtdWNoIG9mDQogdGhlIGRpc2N1c3Npb24gYXMgb2YgbGF0ZSBo YXMgYmVlbiBhYm91dCBzeW50YXgsIHNlbWFudGljcyBpcyBlcXVhbGx5IGltcG9ydGFudCwgYW5k IG11c3QgYmUgY29uc2lkZXJlZCBieSBwcm9maWxlIHdyaXRlcnMgYW5kIGRlcGxveWVycy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+SSBiZWxpZXZlIHRoYXQgdGhlIG5ldyBzZWN0aW9uIGNvbnRhaW5z IG9ubHkgc3RhdGVtZW50cyB0aGF0IGFyZSBhbHJlYWR5IGZhY3R1YWxseSBhY2N1cmF0ZSByZXF1 aXJlbWVudHMgYnV0IHRoYXQNCiB3ZXJlIHByZXZpb3VzbHkgdW5zdGF0ZWQuJm5ic3A7IFRoZSBl ZGl0b3LigJlzIGRyYWZ0IG1ha2VzIHRoZXNlIHJlcXVpcmVtZW50cyBleHBsaWNpdC4mbmJzcDsg RmVlZGJhY2sgb24gaG93IHRvIG1ha2UgdGhlc2UgcmVxdWlyZW1lbnRzIGV2ZW4gbW9yZSBjbGVh ciwgaXMgb2YgY291cnNlLCB3ZWxjb21lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50 QGlldGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENn YVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1fWEY5OTR6Vm4xX0FlUy1DelN0cU9RYVZR cHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTNzMUdDYy0zZzJLVV9wTjZIdldWSGdXQkpYczZPR1BZ OEstbkZhcVV4S1EmYW1wO2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1fWEY5OTR6Vm4xX0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTNz MUdDYy0zZzJLVV9wTjZIdldWSGdXQkpYczZPR1BZOEstbkZhcVV4S1EmYW1wO2U9PC9hPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWQtZXZlbnRAaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0504488CA9AEF47C8C049E90F5D20CY4PR21MB0504namp_-- From nobody Thu Jun 29 11:02:59 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6032B128ACA for ; Thu, 29 Jun 2017 11:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 266sRaPKQJgG for ; Thu, 29 Jun 2017 11:02:55 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DB7126B7E for ; Thu, 29 Jun 2017 11:02:55 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id h64so11593144iod.0 for ; Thu, 29 Jun 2017 11:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6BUdLObogspJVKp16cVO8bVg1i5Q7MIZDJ46Jqu2DDM=; b=TbMkOgP7rgUiS+wIqzOd+DzCt5OWy+04oXx/HyRuP2vrqMzARM2mDBK81fbmBap+io IJjVWPuZ8Zl51gTBAO/CGGmZoxbmY761O+d8kMJwphh/4wALLjLKg0ulDHmYfIdGwyKk Cl6irGiapyQvuH62ohroLJSwySgVc6xXtYOqHl7zS4/zfktXLnw3gDJgKSjXYYBFA5aw 5wSeVZeF1GaNZ662aqzRz5PBAg839aYEhzX31hCRmUtQWvFZEU9Zv0P9PPId+YFH8068 o/EVvvzox9YD3jMsRUQT6S7QMxFZMFlZPSjJjPPMjR8iuAb/8SoQUW8bEmy0meNt8l6v fLUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6BUdLObogspJVKp16cVO8bVg1i5Q7MIZDJ46Jqu2DDM=; b=EmU5u7H8UwHpszDn2epCkTeyEUnK5YVMiQuJyH0Wy5Hqr6KVIubWo98RtJe/58OVc+ uAyOBimewMZirT3jz/DoxqK9m/QfQCkPoApTNGvjEHqdFiCvhWVaRYY9BTngfrf9naMJ zgWC428xkzA6guOp4PIQ97T+X+ngmB6R5BicJ9UE5ymFVf8R8xsImHiwTAAv22W6RDoV nBRQBy6OKtRfJComBACqyOEVvy42uDS7d+EHuI2y8ryS4nNx+sdFl2gD2Fbm/X5PEJia sEctjUzmTHuH1mPR3bVBziJOGqUDc6eTFlZ0xiIjBoZJVGrupgW4TcCEzRfV7YTCADRe uAbw== X-Gm-Message-State: AKS2vOytkW8q/EUjLkS4GM7Wp0vXClaNaGRYaCdbLZNRDwIHL/BwdmM5 ljPw6OcX8DvbZ8IUVcKmuzmYtmKeLosa X-Received: by 10.107.6.23 with SMTP id 23mr20047560iog.122.1498759374374; Thu, 29 Jun 2017 11:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 29 Jun 2017 11:02:33 -0700 (PDT) In-Reply-To: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> From: Marius Scurtescu Date: Thu, 29 Jun 2017 11:02:33 -0700 Message-ID: To: John Bradley Cc: "Phil Hunt (IDM)" , William Denniss , Michael Jones , "id-event@ietf.org" Content-Type: multipart/alternative; boundary="001a113f8e7e1dbf4f05531d1ccf" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 18:02:58 -0000 --001a113f8e7e1dbf4f05531d1ccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for exp If we allow only one profile per SET then maybe we need a profile URI and this URI should be present as a top level claim? Or even adding the profile URI to the JWT header? Having to fully parse the SET to infer the profile based on event types only to very the signature does not sound right. Also, mapping from event type URIs to profiles is not clear. Imagine a receiver that accepts events (it must validate at least syntax and signatures) then further distributes them based on either audience or event type. You don't want to update this receiver every single time a profile adds a new event type. Another potential solution for key location is to have the transmitter explicitly publish it, as mentioned in another email thread. We still have one open issue: SET issuer vs sub context issuer. Asking profiles to deal with this does not sound safe nor enough to me. Marius On Thu, Jun 29, 2017 at 10:37 AM, John Bradley wrote: > I agree on exp. > > I think defining trust relationships should be in the profiles as they ma= y > be quite different. > > That is why mixing events in the same message will be a problem. I > thought we agreed on that. > > Trying to define a fixed trust relationship for the transport is likely > going to cause people to roll there own. > > Even in Connect for specific verticals like finance we see diffrences in > registration etc to reflect the need to accommodate eIDS and other > regulations. > > One size fits all is great if you are the one size. > > I do think we should encourage people to use JWKS URI discovers from > issuer meta-data based on the issuers well-known as a pattern that has > proven to be repeatable. > > It would be nice if we had those specs done in the IETF:) > > John B. > > > On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) wrote= : > > I agree on the exp part. > > Regarding the second part. I would like to see more discussion. > > For example, in the the use cases, there may be compatibility issues if > different set profiles cannot be sent over the same stream. > > Such profiles should avoid things like requiring signing and encryption > without consideration regarding how they are transferred. Also key > management might be better tied up in how the streams are manages because > the network relationship may define the requirements rather than the data= . > > My initial reaction is, the profiles should stick to the data and valid > interpretation. > > If the group agrees I will merge the exp and post over the weekend. > > I can merge the second part if there is a strong agreement to do so. > > Thanks! > > Phil > > On Jun 28, 2017, at 5:24 PM, William Denniss wrote: > > Thank you Mike for working on this. I'm very happy with the change > regarding the "exp" claim, and believe it is the best resolution to the "= ID > Token" confusion concern. > > By making the "exp" claim that is already > > NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID > Tokens and SET uniqueness guarantee that is desired, allowing these two > types of JWTs to be used with a common issuer. This also allows "sub" to = be > used for its intended purpose (as defined by RFC7519) without modificatio= n, > which other working groups that wish to profile SET have expressed an > interest to do > > The benefit the community will gain from the SET standard overall is a > standard way to express events that won't conflict with ID Token (no "iss= " > partitioning required). With Mike's changes we achieve that, and in a way > that retains the original simplicity, extensibility and generalizability > goals of SET by not redefining any of JWT's standard claims. > > > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones > wrote: > >> Hi folks, >> >> >> >> I wanted to give you a heads-up about two SET spec updates in the curren= t >> editor=E2=80=99s draft before they are published. >> >> >> >> The first solves the potential ID Token / SET confusion problem by >> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens >> could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID >> Token claim, SETs would therefore be rejected by existing ID Token >> validation code. Note that this solution is already recommended in the >> specification. The editor=E2=80=99s draft update makes this solution ma= ndatory. >> This provides a simple and durable solution to the problem we agreed to >> solve at IETF 98 in Chicago and that has been the subject of much >> discussion since. >> >> >> >> The second adds the following new section: >> >> >> >> Requirements for SET Profiles >> >> >> >> Profile Specifications for SETs define the syntax and semantics of SETs >> conforming to that SET profile and rules for validating those SETs. The >> syntax defined by profiling specifications includes what claims and even= t >> payload values are used by SETs utilizing the profile. >> >> >> >> Defining the semantics of the SET contents for SETs utilizing the profil= e >> is equally important. Possibly most important is defining the procedures >> used to validate the SET issuer and to obtain the keys controlled by the >> issuer that were used for cryptographic operations used in the JWT >> representing the SET. For instance, some profiles may define an algorith= m >> for retrieving the SET issuer's keys that uses the iss claim value as >> its input. >> >> >> >> Profile Specifications MUST clearly specify the steps that a recipient o= f >> a SET utilizing that profile MUST perform to validate that the SET is bo= th >> syntactically and semantically valid. >> >> >> >> It=E2=80=99s included to inform profile writers about what they must do = to be >> able to use SETs securely. While much of the discussion as of late has >> been about syntax, semantics is equally important, and must be considere= d >> by profile writers and deployers. >> >> >> >> I believe that the new section contains only statements that are already >> factually accurate requirements but that were previously unstated. The >> editor=E2=80=99s draft makes these requirements explicit. Feedback on h= ow to make >> these requirements even more clear, is of course, welcomed. >> >> >> >> Best >> wishes, >> >> -- Mike >> >> >> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS- > CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K- > nFaqUxKQ&e=3D > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a113f8e7e1dbf4f05531d1ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for exp

If we allow only one profile= per SET then maybe we need a profile URI and this URI should be present as= a top level claim? Or even adding the profile URI to the JWT header?
=

Having to fully parse the SET to infer the profile base= d on event types only to very the signature does not sound right. Also, map= ping from event type URIs to profiles is not clear. Imagine a receiver that= accepts events (it must validate at least syntax and signatures) then furt= her distributes them based on either audience or event type. You don't = want to update this receiver every single time a profile adds a new event t= ype.

Another potential solution for key location i= s to have the transmitter explicitly publish it, as mentioned in another em= ail thread.

We still have one open issue: SET issu= er vs sub context issuer. Asking profiles to deal with this does not sound = safe nor enough to me.

= Marius

On Thu, Jun 29, 2017 at 10:37 AM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
I agree on exp.

= I think defining trust relationships should be in the profiles as they may = be quite different.

That is why mixing events in t= he same message will be a problem.=C2=A0 I thought we agreed on that.
=

Trying to define a fixed trust relationship for the tra= nsport is likely going to cause people to roll there own.

Even in Connect for specific verticals like finance we see diffrenc= es in registration etc to reflect the need to accommodate eIDS and other re= gulations.

One size fits all is great if you are t= he one size. =C2=A0

I do think we should encourage= people to use JWKS URI discovers from issuer meta-data based on the issuer= s well-known as a pattern that has proven to be repeatable.=C2=A0

It would be nice if we had those specs done in the IETF:)

John B.


On Jun 28, 2017, at 8:38 PM, P= hil Hunt (IDM) <phil.hunt@oracle.com> wrote:

I agre= e on the exp part.=C2=A0

Regarding the second part. I would = like to see more discussion.=C2=A0

For example, in the the u= se cases, there may be compatibility issues if different set profiles canno= t be sent over the same stream.=C2=A0

Such profiles should a= void things like requiring signing and encryption without consideration reg= arding how they are transferred.=C2=A0 Also key management might be better = tied up in how the streams are manages because the network relationship may= define the requirements rather than the data.=C2=A0

My init= ial reaction is, the profiles should stick to the data and valid interpreta= tion.=C2=A0

If the group agrees I will merge the exp and post over t= he weekend.=C2=A0

I can merge the second part if there is a = strong agreement to do so.=C2=A0

Thanks!

Phil
=
=
On Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:
Thank you Mike for = working on this. I'm very happy with the change regarding the "exp= " claim, and believe it is the best resolution to the "ID Token&q= uot; confusion concern.

By making the "exp&qu= ot; claim that is=C2=A0already=C2=A0NOT RECOMMENDED in the current draft a= MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee that i= s desired, allowing these two types of JWTs to be used with a common issuer= . This also allows "sub" to be used for its intended purpose (as = defined by RFC7519) without modification, which other working groups that w= ish to profile SET have expressed an interest to do

The benefit the community will gain from the SET standard overall is a st= andard way to express events that won't conflict with ID Token (no &quo= t;iss" partitioning required). With Mike's changes we achieve that= , and in a way that retains the original simplicity, extensibility and gene= ralizability goals of SET by not redefining any of JWT's standard claim= s.


On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones=C2=A0<<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com>=C2=A0wrote:

Hi folks,=

=C2=A0

I wanted to give you a heads-up about two SET spec updates in the cur= rent editor=E2=80=99s draft before they are published.

=C2=A0

The firs= t solves the potential ID Token / SET confusion problem by requiring that S= ETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens coul= d also be generated by the same issuer.=C2=A0 Because =E2=80=9Cexp=E2=80=9D= is a required ID Token claim, SETs would therefore be rejected by existing= ID Token validation code.=C2=A0 Note that this solution is already recomme= nded in the specification.=C2=A0 The editor=E2=80=99s draft update makes th= is solution mandatory.=C2=A0 This provides a simple and durable solution to= the problem we agreed to solve at IETF 98 in Chicago and that has been the= subject of much discussion since.

= =C2=A0

The second adds the followin= g new section:

=C2=A0=

Requirements for= SET Profiles

=C2= =A0

Profile Specifications for SETs define = the syntax and semantics of SETs conforming to that SET profile and rules f= or validating those SETs. The syntax defined by profiling specifications in= cludes what claims and event payload values are used by SETs utilizing the = profile.

=C2=A0=

Defining the semantics of the SET contents for SETs util= izing the profile is equally important. Possibly most important is defining= the procedures used to validate the SET issuer and to obtain the keys cont= rolled by the issuer that were used for cryptographic operations used in th= e JWT representing the SET. For instance, some profiles may define an algor= ithm for retrieving the SET issuer's keys that uses the=C2=A0iss=C2=A0cl= aim value as its input.

=C2= =A0

Profile Specifications MUST clearly spe= cify the steps that a recipient of a SET utilizing that profile MUST perfor= m to validate that the SET is both syntactically and semantically valid.=C2=A0

=C2=A0

It=E2=80=99s included to inform profile writers about what t= hey must do to be able to use SETs securely.=C2=A0 While much of the discus= sion as of late has been about syntax, semantics is equally important, and = must be considered by profile writers and deployers.

=C2=A0

I believe = that the new section contains only statements that are already factually ac= curate requirements but that were previously unstated.=C2=A0 The editor=E2= =80=99s draft makes these requirements explicit.=C2=A0 Feedback on how to m= ake these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0<= u>


__________= _____________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/= listinfo/id-event

_________= ______________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--001a113f8e7e1dbf4f05531d1ccf-- From nobody Thu Jun 29 11:27:32 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E7126D05 for ; Thu, 29 Jun 2017 11:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwtdI7B5xnoC for ; Thu, 29 Jun 2017 11:27:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1691D126B7E for ; Thu, 29 Jun 2017 11:27:27 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5TIRONj011747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 18:27:25 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5TIROlM001901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 18:27:24 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5TIRNtH018383; Thu, 29 Jun 2017 18:27:23 GMT Received: from [192.168.1.25] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 11:27:22 -0700 From: Phil Hunt Message-Id: <39D258DB-3FFA-4218-8C0A-2371EA810628@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3D34EAD0-B92B-4566-99C2-BA623B124C15" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 11:27:18 -0700 In-Reply-To: Cc: John Bradley , William Denniss , "id-event@ietf.org" To: Mike Jones References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 18:27:30 -0000 --Apple-Mail=_3D34EAD0-B92B-4566-99C2-BA623B124C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A SET Profile is just a data message that describes something that = occurred. Nothing more. IMO The trust relationship should not be part of the data profile. Maybe the trust profile is a separate document? But right now it seems = better suited to the Stream systems assuming there are a relatively = limited number of trust relationships. The composition that you propose I believe leads us down the road to a = combinations and permutations problem that will be un-implementable in = practice because every implementer has to implement every trust profile, = every set token format and every transfer method. I think this issue is foundational. Going the wrong way completely = undermines the value of having SETEVENTs. We might as well each go our = own way using JWT only. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 29, 2017, at 10:50 AM, Mike Jones = wrote: >=20 > Thanks, John. > =20 > The good news about key metadata in the IETF is that we=E2=80=99re = nearly done with standardizing the jwks_uri pattern in the IETF, per = https://tools.ietf.org/html/draft-ietf-oauth-discovery-06#section-2 = . (It=E2=80=99s currently = waiting for the AD write-up from EKR.) > =20 > Phil, I believe that all the statements in the new =E2=80=9CRequirements= for SET Profiles=E2=80=9D section are demonstrably true and add no new = requirements. They are there to make requirements that were already = implicit explicit. Phil, if you believe that any of the sentences in = the section are false, please call them out explicitly and say why = they=E2=80=99re false. If one or more of them are false, I=E2=80=99ll = obviously clarify or redact those, while leaving the rest in place as = guidance to users of the spec. > =20 > I=E2=80=99ll point out that even if a profile decided to delegate its = key management to a transport, as you=E2=80=99re advocating, Phil, the = profile would still need to explicitly say that. It wouldn=E2=80=99t be = a complete or usable profile if it didn=E2=80=99t define how to retrieve = the keys used to validate the JWT. So your proposal is one way of a = profile satisfying the requirement =E2=80=9CPossibly most important is = defining the procedures used to validate the SET issuer and to obtain = the keys controlled by the issuer that were used for cryptographic = operations used in the JWT representing the SET.=E2=80=9D Given that = your proposal is a way to satisfy this requirement, I don=E2=80=99t see = any grounds for you to oppose it. In fact, I believe it argues that you = should support it. > =20 > Saying nothing about the semantic requirements is doing no one any = favors. > =20 > Thanks = all, > -- = Mike > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, June 29, 2017 10:37 AM > To: Phil Hunt (IDM) > Cc: William Denniss ; Mike Jones = ; id-event@ietf.org > Subject: Re: [Id-event] Heads-up about SET spec updates > =20 > I agree on exp. > =20 > I think defining trust relationships should be in the profiles as they = may be quite different. > =20 > That is why mixing events in the same message will be a problem. I = thought we agreed on that. > =20 > Trying to define a fixed trust relationship for the transport is = likely going to cause people to roll there own. > =20 > Even in Connect for specific verticals like finance we see diffrences = in registration etc to reflect the need to accommodate eIDS and other = regulations. > =20 > One size fits all is great if you are the one size. =20 > =20 > I do think we should encourage people to use JWKS URI discovers from = issuer meta-data based on the issuers well-known as a pattern that has = proven to be repeatable.=20 > =20 > It would be nice if we had those specs done in the IETF:) > =20 > John B. > =20 > =20 > On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) > wrote: > =20 > I agree on the exp part.=20 > =20 > Regarding the second part. I would like to see more discussion.=20 > =20 > For example, in the the use cases, there may be compatibility issues = if different set profiles cannot be sent over the same stream.=20 > =20 > Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred. = Also key management might be better tied up in how the streams are = manages because the network relationship may define the requirements = rather than the data.=20 > =20 > My initial reaction is, the profiles should stick to the data and = valid interpretation.=20 >=20 > If the group agrees I will merge the exp and post over the weekend.=20 > =20 > I can merge the second part if there is a strong agreement to do so.=20= > =20 > Thanks! >=20 > Phil >=20 > On Jun 28, 2017, at 5:24 PM, William Denniss > wrote: >=20 > Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. > =20 > By making the "exp" claim that is already = NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to do > =20 > The benefit the community will gain from the SET standard overall is a = standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. > =20 > =20 > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: > Hi folks, > =20 > I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. > =20 > The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. > =20 > The second adds the following new section: > =20 > Requirements for SET Profiles > =20 > Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. > =20 > Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. > =20 > Profile Specifications MUST clearly specify the steps that a recipient = of a SET utilizing that profile MUST perform to validate that the SET is = both syntactically and semantically valid.=20 > =20 > It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. > =20 > I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. > =20 > Best = wishes, > -- = Mike > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D = =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_3D34EAD0-B92B-4566-99C2-BA623B124C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A SET Profile is just a data message that describes something = that occurred.  Nothing more.

IMO The trust relationship should not = be part of the data profile.

Maybe the trust profile is a separate = document?  But right now it seems better suited to the Stream = systems assuming there are a relatively limited number of trust = relationships.

The composition that you propose I believe leads us down the = road to a combinations and permutations problem that will be = un-implementable in practice because every implementer has to implement = every trust profile, every set token format and every transfer = method.

I = think this issue is foundational.  Going the wrong way completely = undermines the value of having SETEVENTs.  We might as well each go = our own way using JWT only.


On Jun 29, 2017, at 10:50 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks, = John.
 
The good = news about key metadata in the IETF is that we=E2=80=99re nearly done = with standardizing the jwks_uri pattern in the IETF, per https://tools.ietf.org/html/draft-ietf-oauth-discovery-06#secti= on-2.  (It=E2=80=99s currently waiting for the AD write-up from = EKR.)
 
Phil, I = believe that all the statements in the new =E2=80=9CRequirements for SET = Profiles=E2=80=9D section are demonstrably true and add no new = requirements.  They are there to make requirements that were = already implicit explicit.  Phil, if you believe that any of the = sentences in the section are false, please call them out explicitly and = say why they=E2=80=99re false.  If one or more of them are false, = I=E2=80=99ll obviously clarify or redact those, while leaving the rest = in place as guidance to users of the spec.
 
I=E2=80=99ll = point out that even if a profile decided to delegate its key management = to a transport, as you=E2=80=99re advocating, Phil, the profile would = still need to explicitly say that.  It wouldn=E2=80=99t be a = complete or usable profile if it didn=E2=80=99t define how to retrieve = the keys used to validate the JWT.  So your proposal is one way of = a profile satisfying the requirement =E2=80=9CPossibly most important is defining the procedures used to = validate the SET issuer and to obtain the keys controlled by the issuer = that were used for cryptographic operations used in the JWT representing = the SET.=E2=80=9D=   Given that your proposal is a way to satisfy this requirement, I = don=E2=80=99t see any grounds for you to oppose it.  In fact, I = believe it argues that you should support it.
 
Saying = nothing about the semantic requirements is doing no one any favors.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Thanks all,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, June 29, 2017 = 10:37 AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: William Denniss <wdenniss@google.com>; Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Heads-up = about SET spec updates
 
I agree on exp.
 
I think defining trust relationships = should be in the profiles as they may be quite different.
 
That is why mixing events in the same = message will be a problem.  I thought we agreed on that.
 
Trying to define a fixed trust = relationship for the transport is likely going to cause people to roll = there own.
 
Even in Connect for specific verticals like finance we see = diffrences in registration etc to reflect the need to accommodate eIDS = and other regulations.
 
One size fits all is great if you are the one size. =  
 
I do think we should encourage people to use JWKS URI = discovers from issuer meta-data based on the issuers well-known as a = pattern that has proven to be repeatable. 
 
It would be nice if we had those specs = done in the IETF:)
 
John B.
 
 
On Jun 28, 2017, at 8:38 = PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
 
I agree on the exp = part. 
 
Regarding the second = part. I would like to see more discussion. 
 
For example, in the the = use cases, there may be compatibility issues if different set profiles = cannot be sent over the same stream. 
 
Such profiles should = avoid things like requiring signing and encryption without consideration = regarding how they are transferred.  Also key management might be = better tied up in how the streams are manages because the network = relationship may define the requirements rather than the data. 
 
My initial reaction is, = the profiles should stick to the data and valid interpretation. 

If the group agrees I will merge the exp and = post over the weekend. 
 
I can merge the second = part if there is a strong agreement to do so. 
 
Thanks!

Phil


On Jun 28, 2017, at 5:24 PM, = William Denniss <wdenniss@google.com> wrote:

Thank you Mike for working on this. I'm very = happy with the change regarding the "exp" claim, and believe it is the = best resolution to the "ID Token" confusion concern.
 
By making the "exp" = claim that is already NOT RECOMMENDED in the = current draft a MUST NOT, we can provide the ID Tokens and SET = uniqueness guarantee that is desired, allowing these two types of JWTs = to be used with a common issuer. This also allows "sub" to be used for = its intended purpose (as defined by RFC7519) without modification, which = other working groups that wish to profile SET have expressed an interest = to do
 
The benefit the = community will gain from the SET standard overall is a standard way to = express events that won't conflict with ID Token (no "iss" partitioning = required). With Mike's changes we achieve that, and in a way that = retains the original simplicity, extensibility and generalizability = goals of SET by not redefining any of JWT's standard claims.
 
 
On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Hi folks,
 
I= wanted to give you a heads-up about two SET spec updates in the current = editor=E2=80=99s draft before they are published.
 
The first solves the potential ID Token / SET = confusion problem by requiring that SETs not include a top-level = =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also be generated by = the same issuer.  Because =E2=80=9Cexp=E2=80=9D is a required ID = Token claim, SETs would therefore be rejected by existing ID Token = validation code.  Note that this solution is already recommended in = the specification.  The editor=E2=80=99s draft update makes this = solution mandatory.  This provides a simple and durable solution to = the problem we agreed to solve at IETF 98 in Chicago and that has been = the subject of much discussion since.
 
The second adds the following new section:
 
Requirements for SET = Profiles
 
Profile Specifications for SETs define = the syntax and semantics of SETs conforming to that SET profile and = rules for validating those SETs. The syntax defined by profiling = specifications includes what claims and event payload values are used by = SETs utilizing the profile.
 
Defining the = semantics of the SET contents for SETs utilizing the profile is equally = important. Possibly most important is defining the procedures used to = validate the SET issuer and to obtain the keys controlled by the issuer = that were used for cryptographic operations used in the JWT representing = the SET. For instance, some profiles may define an algorithm for = retrieving the SET issuer's keys that uses the iss claim value as its = input.
 
Profile Specifications MUST clearly = specify the steps that a recipient of a SET utilizing that profile MUST = perform to validate that the SET is both syntactically and semantically = valid. 
 
It=E2=80=99s included to = inform profile writers about what they must do to be able to use SETs = securely.  While much of the discussion as of late has been about = syntax, semantics is equally important, and must be considered by = profile writers and deployers.
 
I= believe that the new section contains only statements that are already = factually accurate requirements but that were previously unstated.  = The editor=E2=80=99s draft makes these requirements explicit.  = Feedback on how to make these requirements even more clear, is of = course, welcomed.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3D_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2= KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=3D 
_______________________________________________Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
=

= --Apple-Mail=_3D34EAD0-B92B-4566-99C2-BA623B124C15-- From nobody Thu Jun 29 12:49:59 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A4129B55 for ; Thu, 29 Jun 2017 12:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CLSu25sK7Ez for ; Thu, 29 Jun 2017 12:49:54 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3453129B8C for ; Thu, 29 Jun 2017 12:49:52 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f92so83154113qtb.2 for ; Thu, 29 Jun 2017 12:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b5xeEcyakCAXPnnU5eSilbOG+KnNfec79hUkUwAXFHA=; b=HpDYNyz6+qr2PghWhCinjPByzm+V26m9veAGrH7zJYGh7SW/8IB4OQ3SnmmBNYzHbH IyKyx7JqSg2n4Vi2VF01snfsNN0KSAKfOplewvt6kjR9EwHXOiMGiAzmwW9JDh2tn9OC WY14RYSzYPx94NWtlbD3oOVN3I2OAs1JPvnyOnQlyZ6q831xZPpy8SiOOrRX1T4Dt2F8 MR/f1oFW8DBh4WghR066MJCKbPYrUmlB28Mhp3AkxpvapWN+XLyuNoFRgbip++vabqeB KCB7fceFhXlYG+Wc84eVaEN+U1nIwjCgzuBzjWwguDSI+Y6e03XsrEkGuDLRUq/kn2qM l+Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b5xeEcyakCAXPnnU5eSilbOG+KnNfec79hUkUwAXFHA=; b=XHnwRb2lqCBjPJaBPUZLtZWPwqBrDJBnc1MsnA/E5FPlQLpcJ+JJk3FUoeKIT0uYid R8ggLCAa3JhqBPg/UPK2+8gGdIpkQsbRrAvGWBbl90QuzpAUcj3yt2/ZvB7l5HgG0m0e 1p/F69VCbotCgwDjiACILO79c4W7ctSi/ILMi1dNdHrmHCBqMiRggidBbIFQjSARPtG9 YPUlgTRKrkRn/rc0rS45oaw11vkSJSzGuzYlyRjSmU0tH0oN4Ip57bhOFmZu7uKRwK1s x/eIun8KkG4VgXRDW5TIKA2GQCyMsa1sGJvJLZEbmeoIEGKn/jQamWLs4++xF+L9lMpT k5qA== X-Gm-Message-State: AKS2vOyT9Wfj3PFyhxTUMljIy7PxtXXpTJgWF/hhEKO972bD2t0WnmuO vkna4xsmHhQJ4328gs+t5dsrYCF+Xg== X-Received: by 10.200.61.130 with SMTP id v2mr13358088qtf.230.1498764328737; Thu, 29 Jun 2017 12:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.132 with HTTP; Thu, 29 Jun 2017 12:25:07 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Thu, 29 Jun 2017 12:25:07 -0700 Message-ID: To: "Phil Hunt (IDM)" Cc: William Denniss , Mike Jones , "id-event@ietf.org" Content-Type: multipart/alternative; boundary="f403045e8e566aa2f105531e4394" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:49:57 -0000 --f403045e8e566aa2f105531e4394 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Phil wrt asking for more discussion, I appreciate you making the suggestion on behalf of the chairs. It does seem there is a reasonable amount of discussion going on now would you not agree? I'd like to get the doc updated in time for Prague so that we have a clear reference point for discussion there and then. Unclear why you would post a change when it was Mike that did this work. Am I missing something? Mike: would you update the doc with what you think is rough consensus when you have time so that we can have a crisp discussion in Prague? On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) wrote: > I agree on the exp part. > > Regarding the second part. I would like to see more discussion. > > For example, in the the use cases, there may be compatibility issues if > different set profiles cannot be sent over the same stream. > > Such profiles should avoid things like requiring signing and encryption > without consideration regarding how they are transferred. Also key > management might be better tied up in how the streams are manages because > the network relationship may define the requirements rather than the data= . > > My initial reaction is, the profiles should stick to the data and valid > interpretation. > > If the group agrees I will merge the exp and post over the weekend. > > I can merge the second part if there is a strong agreement to do so. > > Thanks! > > Phil > > On Jun 28, 2017, at 5:24 PM, William Denniss wrote: > > Thank you Mike for working on this. I'm very happy with the change > regarding the "exp" claim, and believe it is the best resolution to the "= ID > Token" confusion concern. > > By making the "exp" claim that is already > > NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID > Tokens and SET uniqueness guarantee that is desired, allowing these two > types of JWTs to be used with a common issuer. This also allows "sub" to = be > used for its intended purpose (as defined by RFC7519) without modificatio= n, > which other working groups that wish to profile SET have expressed an > interest to do > > The benefit the community will gain from the SET standard overall is a > standard way to express events that won't conflict with ID Token (no "iss= " > partitioning required). With Mike's changes we achieve that, and in a way > that retains the original simplicity, extensibility and generalizability > goals of SET by not redefining any of JWT's standard claims. > > > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones > wrote: > >> Hi folks, >> >> >> >> I wanted to give you a heads-up about two SET spec updates in the curren= t >> editor=E2=80=99s draft before they are published. >> >> >> >> The first solves the potential ID Token / SET confusion problem by >> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens >> could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID >> Token claim, SETs would therefore be rejected by existing ID Token >> validation code. Note that this solution is already recommended in the >> specification. The editor=E2=80=99s draft update makes this solution ma= ndatory. >> This provides a simple and durable solution to the problem we agreed to >> solve at IETF 98 in Chicago and that has been the subject of much >> discussion since. >> >> >> >> The second adds the following new section: >> >> >> >> Requirements for SET Profiles >> >> >> >> Profile Specifications for SETs define the syntax and semantics of SETs >> conforming to that SET profile and rules for validating those SETs. The >> syntax defined by profiling specifications includes what claims and even= t >> payload values are used by SETs utilizing the profile. >> >> >> >> Defining the semantics of the SET contents for SETs utilizing the profil= e >> is equally important. Possibly most important is defining the procedures >> used to validate the SET issuer and to obtain the keys controlled by the >> issuer that were used for cryptographic operations used in the JWT >> representing the SET. For instance, some profiles may define an algorith= m >> for retrieving the SET issuer's keys that uses the iss claim value as >> its input. >> >> >> >> Profile Specifications MUST clearly specify the steps that a recipient o= f >> a SET utilizing that profile MUST perform to validate that the SET is bo= th >> syntactically and semantically valid. >> >> >> >> It=E2=80=99s included to inform profile writers about what they must do = to be >> able to use SETs securely. While much of the discussion as of late has >> been about syntax, semantics is equally important, and must be considere= d >> by profile writers and deployers. >> >> >> >> I believe that the new section contains only statements that are already >> factually accurate requirements but that were previously unstated. The >> editor=E2=80=99s draft makes these requirements explicit. Feedback on h= ow to make >> these requirements even more clear, is of course, welcomed. >> >> >> >> Best >> wishes, >> >> -- Mike >> >> >> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS- > CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K- > nFaqUxKQ&e=3D > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --f403045e8e566aa2f105531e4394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil

wrt asking for more discussion,= I appreciate you making the suggestion on behalf of the chairs. It does se= em there is a reasonable amount of discussion going on now would you not ag= ree?

I'd like to get the doc updated in time f= or Prague so that we have a clear reference point for discussion there and = then.

Unclear why you would post a change whe= n it was Mike that did this work. Am I missing something?

Mike: would you update the doc with what you think is rough consens= us when you have time so that we can have a crisp discussion in Prague?



=
On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM)= <phil.hunt@oracle.com> wrote:
I agree on the exp part.=C2=A0

Regarding the second part. I would like t= o see more discussion.=C2=A0

= For example, in the the use cases, there may be compatibility issues if dif= ferent set profiles cannot be sent over the same stream.=C2=A0

Such profiles should avoid things like re= quiring signing and encryption without consideration regarding how they are= transferred.=C2=A0 Also key management might be better tied up in how the = streams are manages because the network relationship may define the require= ments rather than the data.=C2=A0

My initial reaction is, the profiles should stick to the data and vali= d interpretation.=C2=A0

If the group agrees I will merge the exp and= post over the weekend.=C2=A0

I can merge the second part if there is a strong agreement to do so.=C2=A0=

Thanks!

Phil
=

On Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:<= br>
Thank you= Mike for working on this. I'm very happy with the change regarding the= "exp" claim, and believe it is the best resolution to the "= ID Token" confusion concern.

By making the &q= uot;exp" claim that is already NOT RECOMMENDED in t= he current draft a MUST NOT, we can provide the ID Tokens and SET uniquenes= s guarantee that is desired, allowing these two types of JWTs to be used wi= th a common issuer. This also allows "sub" to be used for its int= ended purpose (as defined by RFC7519) without modification, which other wor= king groups that wish to profile SET have expressed an interest to do
=

The benefit the community will gain from the SET standa= rd overall is a standard way to express events that won't conflict with= ID Token (no "iss" partitioning required). With Mike's chang= es we achieve that, and in a way that retains the original simplicity, exte= nsibility and generalizability goals of SET by not redefining any of JWT= 9;s standard claims.

<= br>
On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <= span dir=3D"ltr"><Michael.Jones@microsoft.com> wrote:

Hi folks,

=C2=A0

I wanted to give you a heads-up about two SET spec u= pdates in the current editor=E2=80=99s draft before they are published.<= /u>

=C2=A0

The first solves the potential ID Token / SET confus= ion problem by requiring that SETs not include a top-level =E2=80=9Cexp=E2= =80=9D claim when ID Tokens could also be generated by the same issuer.=C2= =A0 Because =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.=C2=A0 Note tha= t this solution is already recommended in the specification.=C2=A0 The edit= or=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provide= s a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

=C2=A0

The second adds the following new section:=

=C2=A0

Requirements for SET Profiles

=C2=A0

Profile Specifications for SETs define the syntax = and semantics of SETs conforming to that SET profile and rules for validati= ng those SETs. The syntax defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

=C2=A0

Defining the semantics of the SET contents for SET= s utilizing the profile is equally important. Possibly most important is de= fining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's= keys that uses the iss claim value as= its input.

=C2=A0

Profile Specifications MUST clearly specify the st= eps that a recipient of a SET utilizing that profile MUST perform to valida= te that the SET is both syntactically and semantically valid.

=C2=A0

It=E2=80=99s included to inform profile writers abou= t what they must do to be able to use SETs securely.=C2=A0 While much of th= e discussion as of late has been about syntax, semantics is equally importa= nt, and must be considered by profile writers and deployers.

=C2=A0

I believe that the new section contains only stateme= nts that are already factually accurate requirements but that were previous= ly unstated.=C2=A0 The editor=E2=80=99s draft makes these requirements expl= icit.=C2=A0 Feedback on how to make these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0


=

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
=
Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
--f403045e8e566aa2f105531e4394-- From nobody Thu Jun 29 12:58:08 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF17F129461 for ; Thu, 29 Jun 2017 12:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fZo6zzjlo0j for ; Thu, 29 Jun 2017 12:58:02 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89251292FD for ; Thu, 29 Jun 2017 12:58:02 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5TJvwQf017784 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 19:57:58 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5TJvwnm018148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 19:57:58 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5TJvw7r029102; Thu, 29 Jun 2017 19:57:58 GMT Received: from [192.168.1.25] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 12:57:57 -0700 From: Phil Hunt Message-Id: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_755AD79E-B3BC-49CF-AFB3-F2D042432A4A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 12:57:56 -0700 In-Reply-To: Cc: William Denniss , Mike Jones , "id-event@ietf.org" To: Dick Hardt References: X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:58:06 -0000 --Apple-Mail=_755AD79E-B3BC-49CF-AFB3-F2D042432A4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dick, The section is a brand new section. It seems to me that has not been any = (or limited) discussion to warrant putting it in the document. It = certainly came to me as a surprise. I think the issue of trust model needs to be discussed. It may not = belong here at all. Please advise. Do you want it posted in spite of consensus? Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: >=20 > Hi Phil >=20 > wrt asking for more discussion, I appreciate you making the suggestion = on behalf of the chairs. It does seem there is a reasonable amount of = discussion going on now would you not agree? >=20 > I'd like to get the doc updated in time for Prague so that we have a = clear reference point for discussion there and then. >=20 > Unclear why you would post a change when it was Mike that did this = work. Am I missing something? >=20 > Mike: would you update the doc with what you think is rough consensus = when you have time so that we can have a crisp discussion in Prague? >=20 >=20 >=20 > On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) > wrote: > I agree on the exp part.=20 >=20 > Regarding the second part. I would like to see more discussion.=20 >=20 > For example, in the the use cases, there may be compatibility issues = if different set profiles cannot be sent over the same stream.=20 >=20 > Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred. = Also key management might be better tied up in how the streams are = manages because the network relationship may define the requirements = rather than the data.=20 >=20 > My initial reaction is, the profiles should stick to the data and = valid interpretation.=20 >=20 > If the group agrees I will merge the exp and post over the weekend.=20 >=20 > I can merge the second part if there is a strong agreement to do so.=20= >=20 > Thanks! >=20 > Phil >=20 > On Jun 28, 2017, at 5:24 PM, William Denniss > wrote: >=20 >> Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. >>=20 >> By making the "exp" claim that is already = NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to do >>=20 >> The benefit the community will gain from the SET standard overall is = a standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. >>=20 >>=20 >> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: >> Hi folks, >>=20 >> =20 >>=20 >> I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. >>=20 >> =20 >>=20 >> The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. >>=20 >> =20 >>=20 >> The second adds the following new section: >>=20 >> =20 >>=20 >> Requirements for SET Profiles <> >> =20 >> Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. >> =20 >> Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. >> =20 >> Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid. >> =20 >>=20 >> It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. >>=20 >> =20 >>=20 >> I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. >>=20 >> =20 >>=20 >> Best = wishes, >>=20 >> -- = Mike >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D = =20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 >=20 >=20 > --=20 > Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZt= YUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBN= GE&e=3D=20 --Apple-Mail=_755AD79E-B3BC-49CF-AFB3-F2D042432A4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dick,

The section is a brand new section. It = seems to me that has not been any (or limited) discussion to warrant = putting it in the document.  It certainly came to me as a = surprise.

I = think the issue of trust model needs to be discussed.  It may not = belong here at all.

Please advise.  Do you want it posted in spite of = consensus?

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Phil

wrt= asking for more discussion, I appreciate you making the suggestion on = behalf of the chairs. It does seem there is a reasonable amount of = discussion going on now would you not agree?

I'd like to get the doc updated in time = for Prague so that we have a clear reference point for discussion there = and then.

Unclear why you would post a change when it was Mike that did = this work. Am I missing something?

Mike: would you update the doc with = what you think is rough consensus when you have time so that we can have = a crisp discussion in Prague?



On Wed, = Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I agree on the exp part. 

Regarding the second part. I would like to see more = discussion. 

For example, in the the use cases, there may be compatibility = issues if different set profiles cannot be sent over the same = stream. 

Such profiles = should avoid things like requiring signing and encryption without = consideration regarding how they are transferred.  Also key = management might be better tied up in how the streams are manages = because the network relationship may define the requirements rather than = the data. 

My initial = reaction is, the profiles should stick to the data and valid = interpretation. 

If the group agrees I = will merge the exp and post over the weekend. 

I can merge the second part if there is a strong agreement to = do so. 

Thanks!

Phil
On Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you Mike for working on = this. I'm very happy with the change regarding the "exp" claim, and = believe it is the best resolution to the "ID Token" confusion = concern.

By = making the "exp" claim that is already NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to = do

The benefit = the community will gain from the SET standard overall is a standard way = to express events that won't conflict with ID Token (no "iss" = partitioning required). With Mike's changes we achieve that, and in a = way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims.


On Wed, = Jun 28, 2017 at 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Hi folks,

 

I wanted to give you a heads-up about two SET spec = updates in the current editor=E2=80=99s draft before they are = published.

 

The first solves the potential ID Token / SET = confusion problem by requiring that SETs not include a top-level = =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also be generated by = the same issuer.  Because =E2=80=9Cexp=E2=80=9D is a required ID = Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note = that this solution is already recommended in the specification.  = The editor=E2=80=99s draft update makes this solution mandatory.  = This provides a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much = discussion since.

 

The second adds the following new section:

 

Requirements for SET Profiles

 

Profile Specifications for SETs define the = syntax and semantics of SETs conforming to that SET profile and rules = for validating those SETs. The syntax defined by profiling specifications includes what claims and event payload values are used = by SETs utilizing the profile.

 

Defining the semantics of the SET contents for = SETs utilizing the profile is equally important. Possibly most important = is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used = for cryptographic operations used in the JWT representing the SET. For = instance, some profiles may define an algorithm for retrieving the SET = issuer's keys that uses the iss claim value as its = input.

 

Profile Specifications MUST clearly specify the = steps that a recipient of a SET utilizing that profile MUST perform to = validate that the SET is both syntactically and semantically valid.

 

It=E2=80=99s included to inform profile writers = about what they must do to be able to use SETs securely.  While = much of the discussion as of late has been about syntax, semantics is = equally important, and must be considered by profile writers and deployers.

 

I believe that the new section contains only = statements that are already factually accurate requirements but that = were previously unstated.  The editor=E2=80=99s draft makes these = requirements explicit.  Feedback on how to make these requirements even more clear, is of course, welcomed.

 

         =             &n= bsp;                  &nb= sp;            = ;           Best wishes,

         =             &n= bsp;                  &nb= sp;            = ;           -- Mike

 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
Subscribe to the HARDTWARE mail list to = learn about projects I am working = on!
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjU= eXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D

= --Apple-Mail=_755AD79E-B3BC-49CF-AFB3-F2D042432A4A-- From nobody Thu Jun 29 13:51:23 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377C112EAC4 for ; Thu, 29 Jun 2017 13:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfz4GCenS9Du for ; Thu, 29 Jun 2017 13:51:11 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876B712EAFA for ; Thu, 29 Jun 2017 13:51:11 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id i2so84570417qta.3 for ; Thu, 29 Jun 2017 13:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vs/XkJ5bZ4iJOg1eMDLcTSBOSthYGma424Aea8rTsu4=; b=m/9Y+Z29CcJtNXM0w1KLuKywAWGRBlX18+mPnr3KXqoBvu9yy/y8f48NK1RLjHDwG5 ueP6a3kkMnQeizaihPYXwAz7I70dKXs5a0rsJYixKWoAFQZmCIJ8qFoN2RCtPUnDinVE qIkjqD6uBH6ERuuXSiH7yonAmOmBJNuGh8m+qlwE3T+UgDpyOWZhI8p8CckQMyfQgNaR pQ2nL0UAXIS5LWE6RtNwK3uakM1EDme8FfN7Eoq3EogW7m6y1bctL052ogwm4lIb2l6n AiyebIhLcp+vWixN3fy2iUoF2FsfKFcxg0eVYhZVt36GAg19ZIov47munBlNS4NUHZGP fgvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vs/XkJ5bZ4iJOg1eMDLcTSBOSthYGma424Aea8rTsu4=; b=prHwe52xon0NGbuq7AGlsvq6KYAoLBtxf1XL5GuqTc2Rm4h7uOX9cZNXgzFnU8HHgf 1QKc/1U1HO7qSCxmQQz+CI/8QbhTHrwPqGsYGaJYGXGUQUuQGfzjorrkZvh9FaYmauTD VvAiKfH4VLYMwj4CgV2ZCatlNX8ebiARU6X9NWoNGvYQrdriJDXPyeapdfwGnY8fXDhg VNJ4xmjQVE19Nfm2iyoT4T9rN04KGLoMSc6+tJW30jD/z8o0eMO2TFuPHmtUPOvwh2Z3 wzRhdEFk/3Rpmn5i6BzFyqwNJESyPzShToe7c5Vn5WHU2bBOQP2QKXf5VPJw3NN2bIpt NBCQ== X-Gm-Message-State: AKS2vOwmbslVCffFlsg7yNCufVyFucBzkrP9oeacRKtt3FHHsAaBgyvm I/t0nhBd1vZTc8p2650yVUHLqZtbnQ== X-Received: by 10.237.44.7 with SMTP id f7mr23986842qtd.52.1498769470707; Thu, 29 Jun 2017 13:51:10 -0700 (PDT) MIME-Version: 1.0 References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> In-Reply-To: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> From: Dick Hardt Date: Thu, 29 Jun 2017 20:51:00 +0000 Message-ID: To: Phil Hunt Cc: Mike Jones , William Denniss , "id-event@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05df90e6dd5005531f7570" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 20:51:15 -0000 --94eb2c05df90e6dd5005531f7570 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand it is new and that there is contention. We clearly want consensus for us to be done with the draft. I think having it in the next draft anchors the discussion so we can discuss and arrive at consensus or an alternative. So yes, is like a new draft posted so we can discuss. On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote: > Dick, > > The section is a brand new section. It seems to me that has not been any > (or limited) discussion to warrant putting it in the document. It > certainly came to me as a surprise. > > I think the issue of trust model needs to be discussed. It may not belon= g > here at all. > > Please advise. Do you want it posted in spite of consensus? > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: > > Hi Phil > > wrt asking for more discussion, I appreciate you making the suggestion on > behalf of the chairs. It does seem there is a reasonable amount of > discussion going on now would you not agree? > > I'd like to get the doc updated in time for Prague so that we have a clea= r > reference point for discussion there and then. > > Unclear why you would post a change when it was Mike that did this work. > Am I missing something? > > Mike: would you update the doc with what you think is rough consensus whe= n > you have time so that we can have a crisp discussion in Prague? > > > > On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) > wrote: > >> I agree on the exp part. >> >> Regarding the second part. I would like to see more discussion. >> >> For example, in the the use cases, there may be compatibility issues if >> different set profiles cannot be sent over the same stream. >> >> Such profiles should avoid things like requiring signing and encryption >> without consideration regarding how they are transferred. Also key >> management might be better tied up in how the streams are manages becaus= e >> the network relationship may define the requirements rather than the dat= a. >> >> My initial reaction is, the profiles should stick to the data and valid >> interpretation. >> >> If the group agrees I will merge the exp and post over the weekend. >> >> I can merge the second part if there is a strong agreement to do so. >> >> Thanks! >> >> Phil >> >> On Jun 28, 2017, at 5:24 PM, William Denniss wrote= : >> >> Thank you Mike for working on this. I'm very happy with the change >> regarding the "exp" claim, and believe it is the best resolution to the = "ID >> Token" confusion concern. >> >> By making the "exp" claim that is already >> >> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID >> Tokens and SET uniqueness guarantee that is desired, allowing these two >> types of JWTs to be used with a common issuer. This also allows "sub" to= be >> used for its intended purpose (as defined by RFC7519) without modificati= on, >> which other working groups that wish to profile SET have expressed an >> interest to do >> >> The benefit the community will gain from the SET standard overall is a >> standard way to express events that won't conflict with ID Token (no "is= s" >> partitioning required). With Mike's changes we achieve that, and in a wa= y >> that retains the original simplicity, extensibility and generalizability >> goals of SET by not redefining any of JWT's standard claims. >> >> >> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones >> wrote: >> >>> Hi folks, >>> >>> >>> >>> I wanted to give you a heads-up about two SET spec updates in the >>> current editor=E2=80=99s draft before they are published. >>> >>> >>> >>> The first solves the potential ID Token / SET confusion problem by >>> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim= when ID Tokens >>> could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID >>> Token claim, SETs would therefore be rejected by existing ID Token >>> validation code. Note that this solution is already recommended in the >>> specification. The editor=E2=80=99s draft update makes this solution m= andatory. >>> This provides a simple and durable solution to the problem we agreed to >>> solve at IETF 98 in Chicago and that has been the subject of much >>> discussion since. >>> >>> >>> >>> The second adds the following new section: >>> >>> >>> >>> Requirements for SET Profiles >>> >>> >>> >>> Profile Specifications for SETs define the syntax and semantics of SETs >>> conforming to that SET profile and rules for validating those SETs. The >>> syntax defined by profiling specifications includes what claims and eve= nt >>> payload values are used by SETs utilizing the profile. >>> >>> >>> >>> Defining the semantics of the SET contents for SETs utilizing the >>> profile is equally important. Possibly most important is defining the >>> procedures used to validate the SET issuer and to obtain the keys >>> controlled by the issuer that were used for cryptographic operations us= ed >>> in the JWT representing the SET. For instance, some profiles may define= an >>> algorithm for retrieving the SET issuer's keys that uses the iss claim >>> value as its input. >>> >>> >>> >>> Profile Specifications MUST clearly specify the steps that a recipient >>> of a SET utilizing that profile MUST perform to validate that the SET i= s >>> both syntactically and semantically valid. >>> >>> >>> >>> It=E2=80=99s included to inform profile writers about what they must do= to be >>> able to use SETs securely. While much of the discussion as of late has >>> been about syntax, semantics is equally important, and must be consider= ed >>> by profile writers and deployers. >>> >>> >>> >>> I believe that the new section contains only statements that are alread= y >>> factually accurate requirements but that were previously unstated. The >>> editor=E2=80=99s draft makes these requirements explicit. Feedback on = how to make >>> these requirements even more clear, is of course, welcomed. >>> >>> >>> >>> Best >>> wishes, >>> >>> -- Mike >>> >>> >>> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0= 57SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxK= Q&e=3D >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZtY= UVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE= &e=3D > > > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c05df90e6dd5005531f7570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand it is new and that there is contention.= =C2=A0

We clearly want c= onsensus for us to be done with the draft. I think having it in the next dr= aft anchors the discussion so we can discuss and arrive at consensus or an = alternative.=C2=A0

So ye= s, is like a new draft posted so we can discuss.=C2=A0

On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Dick,

The section is a brand new section. It seem= s to me that has not been any (or limited) discussion to warrant putting it= in the document.=C2=A0 It certainly came to me as a surprise.
I think the issue of trust model needs to be discussed.=C2=A0 = It may not belong here at all.

Please advise.=C2= =A0 Do you want it posted in spite of consensus?

<= /div>
Phil

Oracle Corporation, Identi= ty Cloud Services Architect & Standards
@independentid
<= div>www.independ= entid.com
phil.hunt@oracle.com
=

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

=
Hi Phil

wrt asking f= or more discussion, I appreciate you making the suggestion on behalf of the= chairs. It does seem there is a reasonable amount of discussion going on n= ow would you not agree?

I'd like to get the do= c updated in time for Prague so that we have a clear reference point for di= scussion there and then.

Unclear why you woul= d post a change when it was Mike that did this work. Am I missing something= ?

Mike: would you update the doc with what you thi= nk is rough consensus when you have time so that we can have a crisp discus= sion in Prague?



On Wed, Jun 28, 2017 at 5:3= 8 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I agree on the exp part.=C2=A0
=
Regarding the second part. I would like to see more discussion.=C2= =A0

For example, in the the use cases, there may be compatibil= ity issues if different set profiles cannot be sent over the same stream.= =C2=A0

Such profiles should avoid things like requiring signin= g and encryption without consideration regarding how they are transferred.= =C2=A0 Also key management might be better tied up in how the streams are m= anages because the network relationship may define the requirements rather = than the data.=C2=A0

My initial reaction is, the profiles shou= ld stick to the data and valid interpretation.=C2=A0

If the group ag= rees I will merge the exp and post over the weekend.=C2=A0

I c= an merge the second part if there is a strong agreement to do so.=C2=A0

Thanks!

Phil

On Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wr= ote:

Thank you Mike f= or working on this. I'm very happy with the change regarding the "= exp" claim, and believe it is the best resolution to the "ID Toke= n" confusion concern.

By making the "exp= " claim that is already NOT RECOMMENDED in the cur= rent draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guar= antee that is desired, allowing these two types of JWTs to be used with a c= ommon issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other working g= roups that wish to profile SET have expressed an interest to do
<= br>
The benefit the community will gain from the SET standard ove= rall is a standard way to express events that won't conflict with ID To= ken (no "iss" partitioning required). With Mike's changes we = achieve that, and in a way that retains the original simplicity, extensibil= ity and generalizability goals of SET by not redefining any of JWT's st= andard claims.


On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones &= lt;Michael= .Jones@microsoft.com> wrote:

Hi folks,

=C2=A0

I wanted to = give you a heads-up about two SET spec updates in the current editor=E2=80= =99s draft before they are published.

=C2=A0

The first solves the pote= ntial ID Token / SET confusion problem by requiring that SETs not include a= top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also be generat= ed by the same issuer.=C2=A0 Because =E2=80=9Cexp=E2=80=9D is a required ID= Token claim, SETs would therefore be rejected by existing ID Token validation code.=C2=A0 Note tha= t this solution is already recommended in the specification.=C2=A0 The edit= or=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provide= s a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

=C2=A0

The second adds the following new section:<= u>

=C2=A0

<= a>Requirements for SET Profiles=

<= u>=C2=A0

P= rofile Specifications for SETs define the syntax and semantics of SETs conf= orming to that SET profile and rules for validating those SETs. The syntax = defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

<= u>=C2=A0

D= efining the semantics of the SET contents for SETs utilizing the profile is= equally important. Possibly most important is defining the procedures used= to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's= keys that uses the iss claim value as its input.

<= u>=C2=A0

P= rofile Specifications MUST clearly specify the steps that a recipient of a = SET utilizing that profile MUST perform to validate that the SET is both sy= ntactically and semantically valid.

=C2=A0

It=E2=80=99s included to inform profile writers= about what they must do to be able to use SETs securely.=C2=A0 While much = of the discussion as of late has been about syntax, semantics is equally im= portant, and must be considered by profile writers and deployers.

=C2=A0

I believe that the new section contains only statem= ents that are already factually accurate requirements but that were previou= sly unstated.=C2=A0 The editor=E2=80=99s draft makes these requirements exp= licit.=C2=A0 Feedback on how to make these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
Subscribe to the HARDTWARE mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing listId-event@ietf.org
--=
Subscribe to the HARDTWARE mail list to learn about proje= cts I am working on!
--94eb2c05df90e6dd5005531f7570-- From nobody Thu Jun 29 15:04:45 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCFD12EA6A for ; Thu, 29 Jun 2017 15:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0UdLsXzW4Td for ; Thu, 29 Jun 2017 15:04:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0110.outbound.protection.outlook.com [104.47.34.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086F5129B1A for ; Thu, 29 Jun 2017 15:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EebG8Si+nFPjm8g3LOWrPWs1aouyO50oYfznB1+8I4I=; b=O5GYXQgskE9y0Rx00joK3iGCHZ0e2zohu+ilbZcE34WGXFiZ6eVKBZSLHn/YOAHDXIYRWJCprLVlYZmYic0er+GoChinUhwTnQ26g9Pk0WNBHAMJdsb5WMMufbCVyf7AIxS+Yej0lXrqSynPSr3UHXwuGsCuDnlnHM3vBC+QaUg= Received: from BN6PR21MB0500.namprd21.prod.outlook.com (10.172.112.10) by BN6PR21MB0274.namprd21.prod.outlook.com (10.173.203.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.4; Thu, 29 Jun 2017 22:04:40 +0000 Received: from BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) by BN6PR21MB0500.namprd21.prod.outlook.com ([10.172.112.10]) with mapi id 15.01.1240.006; Thu, 29 Jun 2017 22:04:40 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: Agenda request for IETF 99 Prague Thread-Index: AdLxI4erITlOZSbsRjyiIl9JyUcV1A== Date: Thu, 29 Jun 2017 22:04:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-29T15:04:39.0660044-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0274; 7:F1y3cICaAh4hBM1T4gblsv8uB7Q+9CGciMttDxF1nOHZ88OnVfC/wlsCiV3/akpoBprqbmP3zOT72w0Kbd0URzZVKkZWUgcM58dBi+a/yKGYaOMqrMiL7NKv7+NfjtcjiLPZfejRRVavxTST/fxZrJZXJLbUPIURURCjzSKAg1CJi1KJpgyg2jWYxz2CpVwunj3qZCtXhpxkxZlyCSCJqD60nTyHboMqspXb0zg608IPJP8Ko/MkmxCXnfvczNOUYTJZrytz2d+0LthhYk8hMCxBZ/IbieXHmnw4KY2rmSagfudfT5xvUSGYD63uVYcDDH6qeLAPOxnU6Dlw+5J5daX1OYjKvplgJkc2IeowKeb50v0xPl5sjbbOP8Pj+m16dZTPn7tsH7mMV1xMz9TNqo3SNii1RKV9Zz8DOR0i4AFsBp2yOTEjMkKGB2ioA/tBXT1rA2CLdz921KDdxhD6qxwDsJF3a2KNYnMfIDnIsN4meZIHKdZ8KgrS3GZS7o+dHyhJhD07I/DScZPmOE+HvXzQAvNtyxuC0QzWuvLr5+wlwXi2VHDjweGu9bBggPd5VPDfTxnWsyS5TUhNJrryZqa7JbB4QhRJN1illSaX5MwJzhG9BXbCIoT8a/39H4Qu7QUX2EP9kibW+MuuMspa8pfY5KHJAWN/UAoJFBIREbszFEFKpgvcG8PIFjOzVzJJXTb45hZPC+CjeCY4BXn7gs/G5ItVWZJpcBslw6gNSUDF1KbRGpsz1xXuMxAYVBJYcAFFpD3K5CE76T1feLHEHwnq6QKLvGu8udPOWC8W/bSXz1vmgFX5I90kjd5vpo3M x-ms-office365-filtering-correlation-id: ae3a4740-5d92-422c-ae08-08d4bf3ad757 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0274; x-ms-traffictypediagnostic: BN6PR21MB0274: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(21748063052155)(92977632026198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910018)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0274; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39840400002)(39450400003)(39400400002)(39410400002)(5660300001)(6916009)(10090500001)(478600001)(558084003)(72206003)(7736002)(5005710100001)(99286003)(8990500004)(2351001)(189998001)(2501003)(38730400002)(77096006)(6506006)(86362001)(110136004)(106356001)(5640700003)(53936002)(5630700001)(9686003)(6306002)(55016002)(2906002)(6436002)(54896002)(413944005)(86612001)(25786009)(2900100001)(3280700002)(3660700001)(6116002)(790700001)(33656002)(14454004)(102836003)(8936002)(7696004)(81166006)(8676002)(10290500003)(50986999)(54356999)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0274; H:BN6PR21MB0500.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB05009E66CED8047327FF4E10F5D20BN6PR21MB0500namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2017 22:04:40.6375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0274 Archived-At: Subject: [Id-event] Agenda request for IETF 99 Prague X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:04:44 -0000 --_000_BN6PR21MB05009E66CED8047327FF4E10F5D20BN6PR21MB0500namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs, I'd like 20-30 minutes to discuss the status of draft-ietf-secevent-token a= nd next steps for it. Thanks, -- Mike --_000_BN6PR21MB05009E66CED8047327FF4E10F5D20BN6PR21MB0500namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear chairs,

 

I’d like 20-30 minutes to discuss the status o= f draft-ietf-secevent-token and next steps for it.

 

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

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

 

--_000_BN6PR21MB05009E66CED8047327FF4E10F5D20BN6PR21MB0500namp_-- From nobody Thu Jun 29 15:04:52 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648B8129B1A for ; Thu, 29 Jun 2017 15:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1EI-ij2u2Yi for ; Thu, 29 Jun 2017 15:04:42 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E09C129B7A for ; Thu, 29 Jun 2017 15:04:42 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5TM4cPu021005 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 22:04:39 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5TM4cr6026172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2017 22:04:38 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5TM4cCk023009; Thu, 29 Jun 2017 22:04:38 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 15:04:37 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-97BCDD2E-DD5A-4BFD-BF33-B2208547EF44 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 29 Jun 2017 15:04:35 -0700 Cc: Mike Jones , William Denniss , "id-event@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> To: Dick Hardt X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:04:45 -0000 --Apple-Mail-97BCDD2E-DD5A-4BFD-BF33-B2208547EF44 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok.=20 I spoke with Mike and he will post his changes to SET in a new revision over= the weekend.=20 Phil > On Jun 29, 2017, at 1:51 PM, Dick Hardt wrote: >=20 > I understand it is new and that there is contention.=20 >=20 > We clearly want consensus for us to be done with the draft. I think having= it in the next draft anchors the discussion so we can discuss and arrive at= consensus or an alternative.=20 >=20 > So yes, is like a new draft posted so we can discuss.=20 >=20 >> On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote: >> Dick, >>=20 >> The section is a brand new section. It seems to me that has not been any (= or limited) discussion to warrant putting it in the document. It certainly c= ame to me as a surprise. >>=20 >> I think the issue of trust model needs to be discussed. It may not belon= g here at all. >>=20 >> Please advise. Do you want it posted in spite of consensus? >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: >>>=20 >>=20 >>> Hi Phil >>>=20 >>> wrt asking for more discussion, I appreciate you making the suggestion o= n behalf of the chairs. It does seem there is a reasonable amount of discuss= ion going on now would you not agree? >>>=20 >>> I'd like to get the doc updated in time for Prague so that we have a cle= ar reference point for discussion there and then. >>>=20 >>> Unclear why you would post a change when it was Mike that did this work.= Am I missing something? >>>=20 >>> Mike: would you update the doc with what you think is rough consensus wh= en you have time so that we can have a crisp discussion in Prague? >>>=20 >>>=20 >>>=20 >>>> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) = wrote: >>>> I agree on the exp part.=20 >>>>=20 >>>> Regarding the second part. I would like to see more discussion.=20 >>>>=20 >>>> For example, in the the use cases, there may be compatibility issues if= different set profiles cannot be sent over the same stream.=20 >>>>=20 >>>> Such profiles should avoid things like requiring signing and encryption= without consideration regarding how they are transferred. Also key managem= ent might be better tied up in how the streams are manages because the netwo= rk relationship may define the requirements rather than the data.=20 >>>>=20 >>>> My initial reaction is, the profiles should stick to the data and valid= interpretation.=20 >>>>=20 >>>> If the group agrees I will merge the exp and post over the weekend.=20 >>>>=20 >>>> I can merge the second part if there is a strong agreement to do so.=20= >>>>=20 >>>> Thanks! >>>>=20 >>>> Phil >>>>=20 >>>>> On Jun 28, 2017, at 5:24 PM, William Denniss wro= te: >>>>>=20 >>>>> Thank you Mike for working on this. I'm very happy with the change reg= arding the "exp" claim, and believe it is the best resolution to the "ID Tok= en" confusion concern. >>>>>=20 >>>>> By making the "exp" claim that is already NOT RECOMMENDED in the curre= nt draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarant= ee that is desired, allowing these two types of JWTs to be used with a commo= n issuer. This also allows "sub" to be used for its intended purpose (as def= ined by RFC7519) without modification, which other working groups that wish t= o profile SET have expressed an interest to do >>>>>=20 >>>>> The benefit the community will gain from the SET standard overall is a= standard way to express events that won't conflict with ID Token (no "iss" p= artitioning required). With Mike's changes we achieve that, and in a way tha= t retains the original simplicity, extensibility and generalizability goals o= f SET by not redefining any of JWT's standard claims. >>>>>=20 >>>>>=20 >>>>>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones wrote: >>>>>> Hi folks, >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I wanted to give you a heads-up about two SET spec updates in the cur= rent editor=E2=80=99s draft before they are published. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The first solves the potential ID Token / SET confusion problem by re= quiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when I= D Tokens could also be generated by the same issuer. Because =E2=80=9Cexp=E2= =80=9D is a required ID Token claim, SETs would therefore be rejected by exi= sting ID Token validation code. Note that this solution is already recommen= ded in the specification. The editor=E2=80=99s draft update makes this solu= tion mandatory. This provides a simple and durable solution to the problem w= e agreed to solve at IETF 98 in Chicago and that has been the subject of muc= h discussion since. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The second adds the following new section: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Requirements for SET Profiles >>>>>> =20 >>>>>> Profile Specifications for SETs define the syntax and semantics of SE= Ts conforming to that SET profile and rules for validating those SETs. The s= yntax defined by profiling specifications includes what claims and event pay= load values are used by SETs utilizing the profile. >>>>>> =20 >>>>>> Defining the semantics of the SET contents for SETs utilizing the pro= file is equally important. Possibly most important is defining the procedure= s used to validate the SET issuer and to obtain the keys controlled by the i= ssuer that were used for cryptographic operations used in the JWT representi= ng the SET. For instance, some profiles may define an algorithm for retrievi= ng the SET issuer's keys that uses the iss claim value as its input. >>>>>> =20 >>>>>> Profile Specifications MUST clearly specify the steps that a recipien= t of a SET utilizing that profile MUST perform to validate that the SET is b= oth syntactically and semantically valid. >>>>>> =20 >>>>>>=20 >>>>>> It=E2=80=99s included to inform profile writers about what they must d= o to be able to use SETs securely. While much of the discussion as of late h= as been about syntax, semantics is equally important, and must be considered= by profile writers and deployers. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I believe that the new section contains only statements that are alre= ady factually accurate requirements but that were previously unstated. The e= ditor=E2=80=99s draft makes these requirements explicit. Feedback on how to= make these requirements even more clear, is of course, welcomed. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Best w= ishes, >>>>>>=20 >>>>>> -- Mi= ke >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY= 057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ= &e=3D=20 >>>>=20 >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Subscribe to the HARDTWARE mail list to learn about projects I am workin= g on! >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>=20 >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZtYU= Vk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e= =3D=20 >>=20 >=20 > --=20 > Subscribe to the HARDTWARE mail list to learn about projects I am working o= n! --Apple-Mail-97BCDD2E-DD5A-4BFD-BF33-B2208547EF44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ok. 

I spoke with Mike and he wi= ll post his changes to SET in a new revision over the weekend. 

Phil

On Jun 29, 2017, at 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I understand it is new and t= hat there is contention. 

We clearly want consensus for us to be done with the draft. I think ha= ving it in the next draft anchors the discussion so we can discuss and arriv= e at consensus or an alternative. 

So yes, is like a new draft posted so we can discuss. 
On Thu, Jun 29, 2017 at 12:58 PM Phi= l Hunt <phil.hunt@oracle.com&= gt; wrote:
Dick,

The section is a brand new sect= ion. It seems to me that has not been any (or limited) discussion to warrant= putting it in the document.  It certainly came to me as a surprise.

I think the issue of trust model needs to be discusse= d.  It may not belong here at all.

Please advi= se.  Do you want it posted in spite of consensus?

<= div>
Phi= l

Oracle Corporation, Identity Cloud Services Archi= tect & Standards
@independentid
phil.hunt@oracle.com=

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wro= te:

Hi Phil

wrt asking for mor= e discussion, I appreciate you making the suggestion on behalf of the chairs= . It does seem there is a reasonable amount of discussion going on now would= you not agree?

I'd like to get the doc updated in t= ime for Prague so that we have a clear reference point for discussion there a= nd then.

Unclear why you would post a change w= hen it was Mike that did this work. Am I missing something?

Mike: would you update the doc with what you think is rough consens= us when you have time so that we can have a crisp discussion in Prague?



On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <phil.hunt@= oracle.com> wrote:
I agree on the exp part. 

Regarding the second pa= rt. I would like to see more discussion. 

For example, in th= e the use cases, there may be compatibility issues if different set profiles= cannot be sent over the same stream. 

Such profiles should a= void things like requiring signing and encryption without consideration rega= rding how they are transferred.  Also key management might be better ti= ed up in how the streams are manages because the network relationship may de= fine the requirements rather than the data. 

My initial reac= tion is, the profiles should stick to the data and valid interpretation.&nbs= p;

If the group agrees I will merge the exp and post over the weekend= . 

I can merge the second part if there is a strong agreemen= t to do so. 

Thanks!

Phil

On Jun 28, 2017, at 5:24 PM, William Denniss &= lt;wdenniss@google.= com> wrote:

Tha= nk you Mike for working on this. I'm very happy with the change regarding th= e "exp" claim, and believe it is the best resolution to the "ID Token" confu= sion concern.

By making the "exp" claim that is already NOT RECOMMENDED in the current draft a MUST NOT, we can pr= ovide the ID Tokens and SET uniqueness guarantee that is desired, allowing t= hese two types of JWTs to be used with a common issuer. This also allows "su= b" to be used for its intended purpose (as defined by RFC7519) without modif= ication, which other working groups that wish to profile SET have expressed a= n interest to do

The benefit the community will gai= n from the SET standard overall is a standard way to express events that won= 't conflict with ID Token (no "iss" partitioning required). With Mike's chan= ges we achieve that, and in a way that retains the original simplicity, exte= nsibility and generalizability goals of SET by not redefining any of JWT's s= tandard claims.


On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones &l= t;Michael.J= ones@microsoft.com> wrote:

Hi folks,

 

I wanted to give y= ou a heads-up about two SET spec updates in the current editor=E2=80=99s dra= ft before they are published.

 

The first solves the potential ID T= oken / SET confusion problem by requiring that SETs not include a top-level =E2= =80=9Cexp=E2=80=9D claim when ID Tokens could also be generated by the same i= ssuer.  Because =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SET= s would therefore be rejected by existing ID Token validation code.  Note that= this solution is already recommended in the specification.  The editor= =E2=80=99s draft update makes this solution mandatory.  This provides a= simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discus= sion since.

 

=

The second adds the following new section:<= /u>

 

Requirements for SET Profiles

 

Pr= ofile Specifications for SETs define the syntax and semantics of SETs confor= ming to that SET profile and rules for validating those SETs. The syntax def= ined by profiling specifications includes what claims and event payload values are used by SE= Ts utilizing the profile.

 

De= fining the semantics of the SET contents for SETs utilizing the profile is e= qually important. Possibly most important is defining the procedures used to= validate the SET issuer and to obtain the keys controlled by the issuer that were used for c= ryptographic operations used in the JWT representing the SET. For instance, s= ome profiles may define an algorithm for retrieving the SET issuer's keys th= at uses the = iss claim value as its input.

 

Pr= ofile Specifications MUST clearly specify the steps that a recipient of a SE= T utilizing that profile MUST perform to validate that the SET is both synta= ctically and semantically valid.

 =

It=E2=80=99s included to inform profile writers a= bout what they must do to be able to use SETs securely.  While much of t= he discussion as of late has been about syntax, semantics is equally importa= nt, and must be considered by profile writers and deployers.

 

=

I believe that the new section contains only statemen= ts that are already factually accurate requirements but that were previously= unstated.  The editor=E2=80=99s draft makes these requirements explici= t.  Feedback on how to make these requirements even more clear, is of course, welcomed.

 

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;         Best wishes,

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

=  



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
htt= ps://www.ietf.org/mailman/listinfo/id-event




--
Subscribe to the HARDT= WARE mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing list
= Id-event@ietf.org=
--
= --Apple-Mail-97BCDD2E-DD5A-4BFD-BF33-B2208547EF44-- From nobody Thu Jun 29 16:42:43 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76F128C81 for ; Thu, 29 Jun 2017 16:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEWI2EtwkfWl for ; Thu, 29 Jun 2017 16:42:38 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531CA126BF7 for ; Thu, 29 Jun 2017 16:42:38 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id v202so53419125itb.0 for ; Thu, 29 Jun 2017 16:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nWhKMa8jXX0PQbNVCe/bPQJH8gMD+ityYVr8UiqCkTY=; b=a1b6EVnrK2kPXo/jUwZUn/Deqol74ozsXIGpIF1deQOcOodR/uhsZPDfvMyHZd5kGr /sQRPc0aZhzDdwqO6E+1YkFktsM0MMM50YLrrFQ+fIGA22qOzfF1NKdvE+NfZ7eoE+nE +suASa/GSeUpUg2hIjfFQKHv/HRS87+Wh/cYQW1bEwwHJ2bx2oK4Fi/MIXpl6ar8GATJ /9oHmaOcWjh+JT3zinEh64Lnrfy4TNDC0vO+I1a2IiyMxq6eGRye+7/uAMd6J4lqHdkf SWOZ2KNoU2Y9cH2c5rFshO3fqx71dAUI1q1NdhUAkRxx8IUeF/v5r4bvQSp+SRMYdKtH DPZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nWhKMa8jXX0PQbNVCe/bPQJH8gMD+ityYVr8UiqCkTY=; b=eNZ1dVMc7tKXH7j+bG8RsIn8Gi5dm90onKMTmdCYYdAxA2Sjb/GyXAIzEsuoa9G6gg j1SH01Xuxwg5we+vuNDYNK2r2PgWLn1y4j8rRAS5EdZL1e6XiwDv7iELjtH2pZqfO4vW mZDKOXU9pdPgXbN32jBbnuE09Fw5X8nHBOmpEnRyYeQO8Ysdk7AfSStYo3SNX0MqbJit k6XcARZGvX0zvDouGkgeIjxPmlXGV5g2uUGXN0TdSr08RTreNIYw4qceX+aVHPqP1ezR Exn6FLFtuJiAwo5OZC7Aq/D/6/Kz7sg1olb3B4mvBYwIh6jsRcDWcV3a3NDr/EUbgTmi 7gYg== X-Gm-Message-State: AIVw110r8Jb8dg/aqx1F/K80b+4NF5ak1XRIDgQXrfznS/MIxkL0qCrD cV9NGc4pUf8FCjBKojYJyjEFnlFwnrlb X-Received: by 10.36.27.72 with SMTP id 69mr231247its.116.1498779756689; Thu, 29 Jun 2017 16:42:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 29 Jun 2017 16:42:16 -0700 (PDT) In-Reply-To: References: <2104A459-8402-4498-9F7F-3EED264DB4E8@oracle.com> <2F79A80F-AE98-4372-B096-C26ED77F4C3B@mit.edu> <10de4c6f-c0a7-9d9f-c524-fa87048dd580@gmail.com> From: Marius Scurtescu Date: Thu, 29 Jun 2017 16:42:16 -0700 Message-ID: To: Dick Hardt Cc: "Phil Hunt (IDM)" , Yaron Sheffer , SecEvent , Justin Richer Content-Type: multipart/alternative; boundary="001a114495b6ff45e8055321daee" Archived-At: Subject: Re: [Id-event] Use case document X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 23:42:42 -0000 --001a114495b6ff45e8055321daee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I just submitted the RISC use cases at: https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases-00 It is very basic right now, I just wanted to make sure that there is at least a basic version submitted before the deadline. I will expand the descriptions and add diagrams. Let me know if anyone else would like to be an author. Marius Marius On Wed, May 31, 2017 at 6:24 PM, Dick Hardt wrote: > Agreed. There is no requirement for these to be in the same document. > > On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > >> Marius, >> >> Go ahead an submit as an individual draft. I will submit scim cases in a >> separate draft. >> >> Afaik there is no plan to have this he a single wg document. >> >> Phil >> >> On May 31, 2017, at 9:22 PM, Marius Scurtescu >> wrote: >> >> Here is an initial use case document, for now it has only the RISC use >> cases we discussed so far. When Phil gets back I will coordinate with hi= m >> to add SCIM use cases to this same I-D. I will get this into a decent sh= ape >> for the IETF meeting. >> >> Marius >> >> On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffer >> wrote: >> >>> Whatever works for you - and that's the whole point of *individual* >>> I-Ds. >>> >>> Thanks, >>> >>> Yaron >>> >>> On 04/05/17 18:25, Marius Scurtescu wrote: >>> >>> Do we need one document for all use cases (all profiles) or one for eac= h >>> profiles? >>> >>> I am happy to create the one document or the one for RISC (if one per >>> profile). >>> >>> Marius >>> >>> On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer >>> wrote: >>> >>>> My strong preference would be an individual I-D that (as Justin says) >>>> will NOT be pushed to RFC. Why an I-D at all? Because this is what IET= F >>>> folks are used to, and it is referenced from the WG agenda and minutes= . >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> On 04/05/17 07:57, Justin Richer wrote: >>>> >>>> In fact, I=E2=80=99m going to ask that we *not* push a use cases docum= ent >>>> toward RFC. Use case documents are wonderful tools for guiding develop= ment, >>>> but should be discarded as artifacts of that process once said process= is >>>> completed (or even well on its way). >>>> >>>> As such, RFC, wiki, blog post, or anything referenced from the list an= d >>>> easily findable works. >>>> >>>> =E2=80=94 Justin >>>> >>>> On May 3, 2017, at 4:45 PM, Dick Hardt wrote: >>>> >>>> As the more experienced chair, I will defer to Yaron for guidance. >>>> >>>> So far no one has expected it to be adopted as an RFC >>>> >>>> On Wed, May 3, 2017 at 4:39 PM, Phil Hunt wrote= : >>>> >>>>> Depends on what the WG wants. >>>>> >>>>> Email cases, >>>>> Github posted document, >>>>> Individual IDs posted to the working group, or >>>>> an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE has >>>>> RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft >>>>> https://tools.ietf.org/html/draft-ietf-oauth-use-cases-03 >>>>> >>>>> ). >>>>> >>>>> Let us know what form and what format. >>>>> >>>>> We can also use one for OpenID Backchannel Logout. This is >>>>> particularly important because it will be triggered by (or is related= to) >>>>> SCIM and by RISC events such as account resets, authentication factor >>>>> changes etc. >>>>> >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect & Standards >>>>> @independentid >>>>> www.independentid.com >>>>> >>>>> phil.hunt@oracle.com >>>>> >>>>> On May 3, 2017, at 4:31 PM, Dick Hardt wrote: >>>>> >>>>> Hi Phil >>>>> >>>>> per >>>>> >>>>> https://mailarchive.ietf.org/arch/msg/id-event/FGuz9IsUMKqKe >>>>> q2OjEBjCZ9cBcI >>>>> >>>>> >>>>> you offered to put them in a WG doc (see quate below). Would that not >>>>> be an ID. Also, as I read over the document, it is hard to follow wha= t the >>>>> use cases are as it is very verbose. >>>>> >>>>> On Tue, Apr 18, 2017 at 11:27 AM, Phil Hunt ; wrote: >>>>> >>>>> > All, >>>>> > >>>>> > Dick asked me if I would enumerate the SCIM use cases. Here is the= SCIM >>>>> > case. Happy to put these somewhere in a working group document. >>>>> >>>>> >>>>> On Wed, May 3, 2017 at 4:16 PM, Phil Hunt wr >>>>> ote: >>>>> >>>>>> My understanding was you wanted informal cases not IDs. The SCIM >>>>>> cases have been posted to the mailing list. I believe Marius is clos= e on >>>>>> the RISC cases. >>>>>> >>>>>> Phil >>>>>> >>>>>> Oracle Corporation, Identity Cloud Services Architect & Standards >>>>>> @independentid >>>>>> www.independentid.com >>>>>> >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> On May 3, 2017, at 3:56 PM, Dick Hardt wrote: >>>>>> >>>>>> Phil / Marius >>>>>> >>>>>> At the Chicago meeting, the two of you agreed to work on a document >>>>>> containing use cases you considered to be relevant for secevent so t= hat the >>>>>> WG could decide which ones were in scope and which ones were out of = scope. >>>>>> >>>>>> Checking in on the status of the use case document. Would you provid= e >>>>>> an update when you have a chance? >>>>>> >>>>>> /Dick >>>>>> >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzj >>>>>> WwlNKe4C_lLIGk&m=3DHWdy4Q9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g >>>>>> &s=3DJTwCxbXPzY_A62IiywTMIjRB-XsMY8UPafBs4oPwOTc&e=3D >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzj >>>>> WwlNKe4C_lLIGk&m=3DbAI2H661a1QkItfplrd3RIM36dgAhF4WdbWxW8BOy4Q >>>>> &s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS8&e=3D >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Subscribe to the HARDTWARE >>>> >>>> mail list to learn about projects I am working on! >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz >> jWwlNKe4C_lLIGk&m=3DgwGItrqQynlr86zXGtWnR-LWrcrcTS6Ly1w14yDo0v >> k&s=3Dt5e3IvZ_e-KRHUBVMfjtwKEs74yLZva4z-6OkkgmSjo&e=3D >> >> > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > --001a114495b6ff45e8055321daee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just submitted the RISC use cases at:
https:= //tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases-00

It is very basic right now, I just wanted to make su= re that there is at least a basic version submitted before the deadline.

I will expand the descriptions and add diagrams.

Let me know if anyone else would like to be an author= .

Marius


Marius

On Wed, May 31, 2017 at 6:24 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:
Agreed. There is no requirement for these to be in = the same document.

On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Marius,

Go ahead an submit as an individual draft. I will submit scim cases in a = separate draft.=C2=A0

Afaik there is no plan to have this he a s= ingle wg document.=C2=A0

Phil

On May 31, 2017, at 9:22 PM, Marius Scurtescu <mscurtescu@google.com<= /a>> wrote:


<= div class=3D"m_640669497799861768m_-1281316939876395491gmail_signature" dat= a-smartmail=3D"gmail_signature">Marius

On Thu, May 4, 2017 at 11:28 AM, Yaron Sheff= er <yaronf.ietf@gmail.com> wrote:
=20 =20 =20

Whatever works for you - and that's the whole point of *individual* I-Ds.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron


On 04/05/17 18:25, Marius Scurtescu wrote:
Do we need one document for all use cases (all profiles) or one for each profiles?

I am happy to create the one document or the one for RISC (if one per profile).

Marius

On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

My strong preference would be an individual I-D that (as Justin says) will NOT be pushed to RFC. Why an I-D at all? Because this is what IETF folks are used to, and it is referenced from the WG agenda and minutes.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron


On 04/05/17 07:57, Justin Richer wrote:
In fact, I=E2=80=99m going to = ask that we *not* push a use cases document toward RFC. Use case documents are wonderful tools for guiding development, but should be discarded as artifacts of that process once said process is completed (or even well on its way).

As such, RFC, wiki, blog post, or anything referenced from the list and easily findable works.

=C2=A0=E2=80=94 Justin

On May 3, 2017, at 4:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

As the more experienced chair, I will defer to Yaron for guidance.

So far no one has expected it to be adopted as an RFC

On Wed, May 3, 2017 at 4:39 PM, Phil Hunt=C2=A0<phil.hunt@oracle.com>= ;=C2=A0wr= ote:
Depends on what the WG wants.

Email cases,
Github posted document,
Individual IDs posted to the working group, or
an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE has RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft=C2=A0https://tools.ietf.or= g/html/draft-ietf-oauth-use-cases-03).

Let us know what form and what format.

We can also use one for OpenID Backchannel Logout.=C2=A0 This is particularly important because it will be triggered by (or is related to) SCIM and by RISC events such as account resets, authentication factor changes etc.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independent= id
phil.hunt@oracle.com

On May 3, 2017, at 4:31 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

Hi Phil

per=C2=A0


you offered to put them in a WG doc (see quate below). Would that not be an ID. Also, as I read over the document, it is hard to follow what the use cases are as it is very verbose.

On Tue=
, Apr 18, 2017 at 11:27 AM, Phil Hunt <phil.hunt@oracle.com>; wrote=
:

> All,
>
> Dick asked me if I would enumerate the SCIM use cases.  Here is the SC=
IM
> case. Happy to put these somewhere in a working group document.
=
On Wed, May 3, 2017 at 4:16 PM, Phil Hunt=C2=A0&l= t;phil.hunt@oracl= e.com>=C2=A0wrote:
My understanding was you wanted informal cases not IDs. The SCIM cases have been posted to the mailing list. I believe Marius is close on the RISC cases.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independent= id
phil.hunt@oracle.com

On May 3, 2017, at 3:56 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

= Phil / Marius

At the Chicago meeting, the two of you agreed to work on a document containing use cases you considered to be relevant for secevent so that the WG could decide which ones were in scope and which ones were out of scope.

Checking in on the status of the use case document. Would you provide an update when you have a chance?

/Dick

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Deven= t&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&a= mp;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DHWdy4Q= 9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g&s=3DJTwCxbXPzY_A62IiywT= MIjRB-XsMY8UPafBs4oPwOTc&e=3D=C2=A0




--=C2=A0
Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDw= ICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D= JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DbAI2H661a1QkI= tfplrd3RIM36dgAhF4WdbWxW8BOy4Q&s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS8&e=3D

--=C2=A0
Subscribe to the=C2=A0HARDTWARE=C2=A0= mail list to learn about projects I am working on!
__________= _____________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event





<draft-scu= rtescu-secevent-use-cases.txt>
<draft-scurtescu-secevent-use-cases.pdf>



--=
Subscribe to the HARD= TWARE mail list to learn about projects I am working on!

--001a114495b6ff45e8055321daee-- From nobody Thu Jun 29 17:01:31 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733C1124C27 for ; Thu, 29 Jun 2017 17:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzqCA_G325AQ for ; Thu, 29 Jun 2017 17:01:26 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1241200F3 for ; Thu, 29 Jun 2017 17:01:26 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id r30so87444714qtc.0 for ; Thu, 29 Jun 2017 17:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1zB3WIo0I0+uQsrds8OlNkrrylFt8rbqz8S50but/ik=; b=blFuDKoLjKMf6158Ps3Bhdd6KDAhC8bQJuMhL9DZWEkezWT8V/v360gv96CiYIehwn Ako0WULeSRXko/6x4Tlq8eUa+rsn/ievjfzTQdOOM8M5RoVdH1Nz7LfGCXxhqGtLiwts 2wnU1E6NAIlMVFIRhOOQdSunv2zKeywGqMi+3aLAoP84ZSaIpKZKNaeV7cuWaVGKGKp3 pJjW7joyh3Jneu2mTOgLtTzs2fZXDSN8Rr88TE4jWiIWJVMJu7AhKPI0KDcBUXZABSWY js3mIaOKPqdUa7hkGgz5lrnXxv9s06Ce5HyazL5PnTDpHEdtMguT2mVOft9vlHUqV4gF sRGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1zB3WIo0I0+uQsrds8OlNkrrylFt8rbqz8S50but/ik=; b=YLu5r/OK9LsnAJ7z9FGBLsCkmmxirPZzWFSxIlqef5+btzsMpW+jNvfeUKV2RPdKR8 vVbzAyEuc4Z43860MySvAhfPXUe5aYOgKwlF5IPr3IvnD4ZRkCWDAz55B/pNLsOtPVUO PkGEH+1MqHZ4oEeX08jRbG1C1fX7p0V6y5uldB/SOHAjEss6Lzjh1WEpsHveFZYTCQY1 f4+YJ1viX0k0MN+39pjWHEQqfcB5yHTTRvsP6gMfFHy4ShZ5bTItKaOtSJaNY9bVsJfI yabjbaXkVsA7yP/Efjk7LbdlY8FOm0GWxNTrOxaw5HU7Z+YS48vknmY/Oo99kQ6XlRqC BDuQ== X-Gm-Message-State: AKS2vOwEiiUoL9KrDdZZowVrqIGBu0ENaBdX0kXj9C5UXTCow9tkzBS6 H+0fDJ9PjQjGEbI87HPwHws+HzxT0A== X-Received: by 10.200.9.55 with SMTP id t52mr23357184qth.107.1498780885467; Thu, 29 Jun 2017 17:01:25 -0700 (PDT) MIME-Version: 1.0 References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> In-Reply-To: <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> From: Nat Sakimura Date: Fri, 30 Jun 2017 00:01:14 +0000 Message-ID: To: "Phil Hunt (IDM)" , Dick Hardt Cc: William Denniss , Mike Jones , "id-event@ietf.org" Content-Type: multipart/alternative; boundary="001a1144dfa04646d90553221e9c" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:01:29 -0000 --001a1144dfa04646d90553221e9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for a tardy reply, but +1 for the both changes. 'exp' claim requirement is a good practical step with a backward compatibility. Having said that, I believe inferring message types from the existence/absence of a claim is not a good security practice. I would like to see an explicit typing through "typ" claim added as well. Nat On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) wrote: > Ok. > > I spoke with Mike and he will post his changes to SET in a new revision > over the weekend. > > Phil > > On Jun 29, 2017, at 1:51 PM, Dick Hardt wrote: > > I understand it is new and that there is contention. > > We clearly want consensus for us to be done with the draft. I think havin= g > it in the next draft anchors the discussion so we can discuss and arrive = at > consensus or an alternative. > > So yes, is like a new draft posted so we can discuss. > > On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote: > >> Dick, >> >> The section is a brand new section. It seems to me that has not been any >> (or limited) discussion to warrant putting it in the document. It >> certainly came to me as a surprise. >> >> I think the issue of trust model needs to be discussed. It may not >> belong here at all. >> >> Please advise. Do you want it posted in spite of consensus? >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: >> >> Hi Phil >> >> wrt asking for more discussion, I appreciate you making the suggestion o= n >> behalf of the chairs. It does seem there is a reasonable amount of >> discussion going on now would you not agree? >> >> I'd like to get the doc updated in time for Prague so that we have a >> clear reference point for discussion there and then. >> >> Unclear why you would post a change when it was Mike that did this work. >> Am I missing something? >> >> Mike: would you update the doc with what you think is rough consensus >> when you have time so that we can have a crisp discussion in Prague? >> >> >> >> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) >> wrote: >> >>> I agree on the exp part. >>> >>> Regarding the second part. I would like to see more discussion. >>> >>> For example, in the the use cases, there may be compatibility issues if >>> different set profiles cannot be sent over the same stream. >>> >>> Such profiles should avoid things like requiring signing and encryption >>> without consideration regarding how they are transferred. Also key >>> management might be better tied up in how the streams are manages becau= se >>> the network relationship may define the requirements rather than the da= ta. >>> >>> My initial reaction is, the profiles should stick to the data and valid >>> interpretation. >>> >>> If the group agrees I will merge the exp and post over the weekend. >>> >>> I can merge the second part if there is a strong agreement to do so. >>> >>> Thanks! >>> >>> Phil >>> >>> On Jun 28, 2017, at 5:24 PM, William Denniss >>> wrote: >>> >>> Thank you Mike for working on this. I'm very happy with the change >>> regarding the "exp" claim, and believe it is the best resolution to the= "ID >>> Token" confusion concern. >>> >>> By making the "exp" claim that is already >>> >>> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID >>> Tokens and SET uniqueness guarantee that is desired, allowing these two >>> types of JWTs to be used with a common issuer. This also allows "sub" t= o be >>> used for its intended purpose (as defined by RFC7519) without modificat= ion, >>> which other working groups that wish to profile SET have expressed an >>> interest to do >>> >>> The benefit the community will gain from the SET standard overall is a >>> standard way to express events that won't conflict with ID Token (no "i= ss" >>> partitioning required). With Mike's changes we achieve that, and in a w= ay >>> that retains the original simplicity, extensibility and generalizabilit= y >>> goals of SET by not redefining any of JWT's standard claims. >>> >>> >>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones >> > wrote: >>> >>>> Hi folks, >>>> >>>> >>>> >>>> I wanted to give you a heads-up about two SET spec updates in the >>>> current editor=E2=80=99s draft before they are published. >>>> >>>> >>>> >>>> The first solves the potential ID Token / SET confusion problem by >>>> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D clai= m when ID Tokens >>>> could also be generated by the same issuer. Because =E2=80=9Cexp=E2= =80=9D is a required ID >>>> Token claim, SETs would therefore be rejected by existing ID Token >>>> validation code. Note that this solution is already recommended in th= e >>>> specification. The editor=E2=80=99s draft update makes this solution = mandatory. >>>> This provides a simple and durable solution to the problem we agreed t= o >>>> solve at IETF 98 in Chicago and that has been the subject of much >>>> discussion since. >>>> >>>> >>>> >>>> The second adds the following new section: >>>> >>>> >>>> >>>> Requirements for SET Profiles >>>> >>>> >>>> >>>> Profile Specifications for SETs define the syntax and semantics of SET= s >>>> conforming to that SET profile and rules for validating those SETs. Th= e >>>> syntax defined by profiling specifications includes what claims and ev= ent >>>> payload values are used by SETs utilizing the profile. >>>> >>>> >>>> >>>> Defining the semantics of the SET contents for SETs utilizing the >>>> profile is equally important. Possibly most important is defining the >>>> procedures used to validate the SET issuer and to obtain the keys >>>> controlled by the issuer that were used for cryptographic operations u= sed >>>> in the JWT representing the SET. For instance, some profiles may defin= e an >>>> algorithm for retrieving the SET issuer's keys that uses the iss claim >>>> value as its input. >>>> >>>> >>>> >>>> Profile Specifications MUST clearly specify the steps that a recipient >>>> of a SET utilizing that profile MUST perform to validate that the SET = is >>>> both syntactically and semantically valid. >>>> >>>> >>>> >>>> It=E2=80=99s included to inform profile writers about what they must d= o to be >>>> able to use SETs securely. While much of the discussion as of late ha= s >>>> been about syntax, semantics is equally important, and must be conside= red >>>> by profile writers and deployers. >>>> >>>> >>>> >>>> I believe that the new section contains only statements that are >>>> already factually accurate requirements but that were previously unsta= ted. >>>> The editor=E2=80=99s draft makes these requirements explicit. Feedbac= k on how to >>>> make these requirements even more clear, is of course, welcomed. >>>> >>>> >>>> >>>> Best >>>> wishes, >>>> >>>> -- Mik= e >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY= 057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS= -CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >>> >>> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0= 57SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZt= YUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNG= E&e=3D >> >> >> -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --001a1144dfa04646d90553221e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for a tardy reply, but=C2=A0+1 for the both changes.= 'exp' claim requirement is a good practical step with a backward c= ompatibility.=C2=A0
Having said that, I believe inferring message types= from the existence/absence of a claim is not a good security practice. I w= ould like to see an explicit typing through "typ" claim added as = well.=C2=A0

Nat

On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) &l= t;phil.hunt@oracle.com> wrot= e:
Ok.=C2=A0=

I spoke with Mike and he will = post his changes to SET in a new revision over the weekend.=C2=A0
Phil
=

On Jun 29, 2017, at 1:51 PM, Dick Hardt <dick.hardt@gmail.com<= /a>> wrote:



Dick,

The section is a brand new section. It se= ems to me that has not been any (or limited) discussion to warrant putting = it in the document.=C2=A0 It certainly came to me as a surprise.
=
I think the issue of trust model needs to be discussed.=C2= =A0 It may not belong here at all.

Please advise.= =C2=A0 Do you want it posted in spite of consensus?

<= div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap= :break-word">
Phil

O= racle Corporation, Identity Cloud Services Architect & Standards
<= div>@independentid
phil.hunt@oracle.com

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

Hi Phil

wrt asking for more discussion, I appreciate you making the sugges= tion on behalf of the chairs. It does seem there is a reasonable amount of = discussion going on now would you not agree?

I'= ;d like to get the doc updated in time for Prague so that we have a clear r= eference point for discussion there and then.

Unclear why you would post a change when it was Mike that did this work. A= m I missing something?

Mike: would you update the = doc with what you think is rough consensus when you have time so that we ca= n have a crisp discussion in Prague?



On Wed, = Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote= :
I agree on the e= xp part.=C2=A0

Regar= ding the second part. I would like to see more discussion.=C2=A0

For example, in the the use ca= ses, there may be compatibility issues if different set profiles cannot be = sent over the same stream.=C2=A0

Such profiles should avoid things like requiring signing and e= ncryption without consideration regarding how they are transferred.=C2=A0 A= lso key management might be better tied up in how the streams are manages b= ecause the network relationship may define the requirements rather than the= data.=C2=A0

My init= ial reaction is, the profiles should stick to the data and valid interpreta= tion.=C2=A0

If the group agrees I will merge the exp and post over t= he weekend.=C2=A0

I = can merge the second part if there is a strong agreement to do so.=C2=A0

Thanks!

Phil

On Jun 28, 2017, at 5:24 PM, William Denniss <= wdenniss@google.co= m> wrote:

Than= k you Mike for working on this. I'm very happy with the change regardin= g the "exp" claim, and believe it is the best resolution to the &= quot;ID Token" confusion concern.

By making t= he "exp" claim that is already NOT RECOMMENDED= in the current draft a MUST NOT, we can provide the ID Tokens and SET uniq= ueness guarantee that is desired, allowing these two types of JWTs to be us= ed with a common issuer. This also allows "sub" to be used for it= s intended purpose (as defined by RFC7519) without modification, which othe= r working groups that wish to profile SET have expressed an interest to do<= /div>

The benefit the community will gain from the SET s= tandard overall is a standard way to express events that won't conflict= with ID Token (no "iss" partitioning required). With Mike's = changes we achieve that, and in a way that retains the original simplicity,= extensibility and generalizability goals of SET by not redefining any of J= WT's standard claims.


On Wed, Jun 28, 2017 at 5:08 PM, Mike Jo= nes <Michael.Jones@microsoft.com> wrote:

Hi folks,<= /u>

=C2=A0

I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published.

=

=C2=A0

The f= irst solves the potential ID Token / SET confusion problem by requiring tha= t SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens c= ould also be generated by the same issuer.=C2=A0 Because =E2=80=9Cexp=E2=80= =9D is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.=C2=A0 Note tha= t this solution is already recommended in the specification.=C2=A0 The edit= or=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provide= s a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

=C2=A0

The second adds the following new section:<= u>

=C2=A0

<= a>Requirements for SET Profiles=

<= u>=C2=A0

P= rofile Specifications for SETs define the syntax and semantics of SETs conf= orming to that SET profile and rules for validating those SETs. The syntax = defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

<= u>=C2=A0

D= efining the semantics of the SET contents for SETs utilizing the profile is= equally important. Possibly most important is defining the procedures used= to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's= keys that uses the iss claim value as its input.

<= u>=C2=A0

P= rofile Specifications MUST clearly specify the steps that a recipient of a = SET utilizing that profile MUST perform to validate that the SET is both sy= ntactically and semantically valid.

=C2=A0

It=E2=80=99s included to inform profile writers= about what they must do to be able to use SETs securely.=C2=A0 While much = of the discussion as of late has been about syntax, semantics is equally im= portant, and must be considered by profile writers and deployers.

=C2=A0

I believe that the new section contains only statem= ents that are already factually accurate requirements but that were previou= sly unstated.=C2=A0 The editor=E2=80=99s draft makes these requirements exp= licit.=C2=A0 Feedback on how to make these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0



_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
Subscribe to the HARDTWARE mail list to learn about projects I a= m working on!
_______________________________________________
Id-event mailing listId-event@ietf.org
--=
Subscribe to the HARDTWARE mail list to learn about projects I am working on= !
_______________________________________________ Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a1144dfa04646d90553221e9c-- From nobody Thu Jun 29 17:05:39 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D5E129B62 for ; Thu, 29 Jun 2017 17:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGU9oe3HdGqg for ; Thu, 29 Jun 2017 17:05:35 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B893129B1D for ; Thu, 29 Jun 2017 17:05:35 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id i2so87456021qta.3 for ; Thu, 29 Jun 2017 17:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9n9bnEa0GunXo65BsfNGf8nrGzlgvlH59CftUPQQC/I=; b=r2iO3Mtbjxd9TOdv1f62d9Ao9AZgpzVoh2iEPw8M/e1+sTDf5B5gzkOMO3Wqe4LY2t EjSGETW1u1Q1lYW1gD3bZKlKurIwIbSQty8TCU55nkiaWyDmj2B9TjMhtyhUBvb+NnyU BGgZWfXcxLC6HIqOSeqIbKCcno6qz42ckBu7XWEKWBxFUWpq2Hah4H26f924tlpm52wl wFWcRHVCQWflD+UH7XQvEO3Yayg4nkX+F4Y1sNGM5/vKbbRl+YSsRYeY3lxZ/EyTzKzp 6o0qbRV+EV0+i22eXLMmUqyYMlK3UCetJeGVOBU4dKYFDC1SUU+sXMtLX5GyGkp3LUA0 iTBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9n9bnEa0GunXo65BsfNGf8nrGzlgvlH59CftUPQQC/I=; b=F4HMYEVX906g+82O/1tQpTMolWyg9yCxMf4jiEzYRP7LDvJqfqyVVtJvRjltjqnqsa wVCdXDQAagEyN8mODPzpArbE3PT784dsEGu3V7+lk9Jj5l1kyujEw1HGE3AiQj6aCJU/ qPQJsrrXWhZF+sKGUkpibW7VANAAx0YLsnszV/gRvgfQJWs8X27HBV0It0/6w9oiMDT8 QpudCwUIowggFOqOl7qQXdUffBXY2RJuAHPwNV0Vy/DU0rmnuBPS0d5XZjDyfewzrGsZ YtV3VymdlrU1C1GlsU9er6BZIY8d1TFFhR0hbX0y+buIxJxu2gQoI/dKoFzuO3VLA3M3 ZCxA== X-Gm-Message-State: AKS2vOwsquu/qKh+eQHSxqPXRMdBHNxH0uNKzA4CMCrAFQUmIkMs1qt8 5g94cF47uuE0xZlUj2CW1cEF5hFU/A== X-Received: by 10.200.53.243 with SMTP id l48mr24100401qtb.7.1498781134580; Thu, 29 Jun 2017 17:05:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.132 with HTTP; Thu, 29 Jun 2017 17:05:13 -0700 (PDT) In-Reply-To: References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> From: Dick Hardt Date: Thu, 29 Jun 2017 17:05:13 -0700 Message-ID: To: Nat Sakimura Cc: "Phil Hunt (IDM)" , William Denniss , Mike Jones , "id-event@ietf.org" Content-Type: multipart/alternative; boundary="001a114574f41f720a0553222db9" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:05:38 -0000 --001a114574f41f720a0553222db9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable wrote: > Sorry for a tardy reply, but +1 for the both changes. 'exp' claim > requirement is a good practical step with a backward compatibility. > Having said that, I believe inferring message types from the > existence/absence of a claim is not a good security practice. I would lik= e > to see an explicit typing through "typ" claim added as well. > > Nat > > On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) > wrote: > >> Ok. >> >> I spoke with Mike and he will post his changes to SET in a new revision >> over the weekend. >> >> Phil >> >> On Jun 29, 2017, at 1:51 PM, Dick Hardt wrote: >> >> I understand it is new and that there is contention. >> >> We clearly want consensus for us to be done with the draft. I think >> having it in the next draft anchors the discussion so we can discuss and >> arrive at consensus or an alternative. >> >> So yes, is like a new draft posted so we can discuss. >> >> On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote: >> >>> Dick, >>> >>> The section is a brand new section. It seems to me that has not been an= y >>> (or limited) discussion to warrant putting it in the document. It >>> certainly came to me as a surprise. >>> >>> I think the issue of trust model needs to be discussed. It may not >>> belong here at all. >>> >>> Please advise. Do you want it posted in spite of consensus? >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect & Standards >>> @independentid >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: >>> >>> Hi Phil >>> >>> wrt asking for more discussion, I appreciate you making the suggestion >>> on behalf of the chairs. It does seem there is a reasonable amount of >>> discussion going on now would you not agree? >>> >>> I'd like to get the doc updated in time for Prague so that we have a >>> clear reference point for discussion there and then. >>> >>> Unclear why you would post a change when it was Mike that did this work= . >>> Am I missing something? >>> >>> Mike: would you update the doc with what you think is rough consensus >>> when you have time so that we can have a crisp discussion in Prague? >>> >>> >>> >>> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) >>> wrote: >>> >>>> I agree on the exp part. >>>> >>>> Regarding the second part. I would like to see more discussion. >>>> >>>> For example, in the the use cases, there may be compatibility issues i= f >>>> different set profiles cannot be sent over the same stream. >>>> >>>> Such profiles should avoid things like requiring signing and encryptio= n >>>> without consideration regarding how they are transferred. Also key >>>> management might be better tied up in how the streams are manages beca= use >>>> the network relationship may define the requirements rather than the d= ata. >>>> >>>> My initial reaction is, the profiles should stick to the data and vali= d >>>> interpretation. >>>> >>>> If the group agrees I will merge the exp and post over the weekend. >>>> >>>> I can merge the second part if there is a strong agreement to do so. >>>> >>>> Thanks! >>>> >>>> Phil >>>> >>>> On Jun 28, 2017, at 5:24 PM, William Denniss >>>> wrote: >>>> >>>> Thank you Mike for working on this. I'm very happy with the change >>>> regarding the "exp" claim, and believe it is the best resolution to th= e "ID >>>> Token" confusion concern. >>>> >>>> By making the "exp" claim that is already >>>> >>>> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID >>>> Tokens and SET uniqueness guarantee that is desired, allowing these tw= o >>>> types of JWTs to be used with a common issuer. This also allows "sub" = to be >>>> used for its intended purpose (as defined by RFC7519) without modifica= tion, >>>> which other working groups that wish to profile SET have expressed an >>>> interest to do >>>> >>>> The benefit the community will gain from the SET standard overall is a >>>> standard way to express events that won't conflict with ID Token (no "= iss" >>>> partitioning required). With Mike's changes we achieve that, and in a = way >>>> that retains the original simplicity, extensibility and generalizabili= ty >>>> goals of SET by not redefining any of JWT's standard claims. >>>> >>>> >>>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> >>>>> >>>>> I wanted to give you a heads-up about two SET spec updates in the >>>>> current editor=E2=80=99s draft before they are published. >>>>> >>>>> >>>>> >>>>> The first solves the potential ID Token / SET confusion problem by >>>>> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D cla= im when ID Tokens >>>>> could also be generated by the same issuer. Because =E2=80=9Cexp=E2= =80=9D is a required ID >>>>> Token claim, SETs would therefore be rejected by existing ID Token >>>>> validation code. Note that this solution is already recommended in t= he >>>>> specification. The editor=E2=80=99s draft update makes this solution= mandatory. >>>>> This provides a simple and durable solution to the problem we agreed = to >>>>> solve at IETF 98 in Chicago and that has been the subject of much >>>>> discussion since. >>>>> >>>>> >>>>> >>>>> The second adds the following new section: >>>>> >>>>> >>>>> >>>>> Requirements for SET Profiles >>>>> >>>>> >>>>> >>>>> Profile Specifications for SETs define the syntax and semantics of >>>>> SETs conforming to that SET profile and rules for validating those SE= Ts. >>>>> The syntax defined by profiling specifications includes what claims a= nd >>>>> event payload values are used by SETs utilizing the profile. >>>>> >>>>> >>>>> >>>>> Defining the semantics of the SET contents for SETs utilizing the >>>>> profile is equally important. Possibly most important is defining the >>>>> procedures used to validate the SET issuer and to obtain the keys >>>>> controlled by the issuer that were used for cryptographic operations = used >>>>> in the JWT representing the SET. For instance, some profiles may defi= ne an >>>>> algorithm for retrieving the SET issuer's keys that uses the iss >>>>> claim value as its input. >>>>> >>>>> >>>>> >>>>> Profile Specifications MUST clearly specify the steps that a recipien= t >>>>> of a SET utilizing that profile MUST perform to validate that the SET= is >>>>> both syntactically and semantically valid. >>>>> >>>>> >>>>> >>>>> It=E2=80=99s included to inform profile writers about what they must = do to be >>>>> able to use SETs securely. While much of the discussion as of late h= as >>>>> been about syntax, semantics is equally important, and must be consid= ered >>>>> by profile writers and deployers. >>>>> >>>>> >>>>> >>>>> I believe that the new section contains only statements that are >>>>> already factually accurate requirements but that were previously unst= ated. >>>>> The editor=E2=80=99s draft makes these requirements explicit. Feedba= ck on how to >>>>> make these requirements even more clear, is of course, welcomed. >>>>> >>>>> >>>>> >>>>> Best >>>>> wishes, >>>>> >>>>> -- >>>>> Mike >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. >>>> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D >>>> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D >>>> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS- >>>> CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K- >>>> nFaqUxKQ&e=3D >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. >>> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D >>> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D >>> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D >>> ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3D >>> lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D >>> >>> >>> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a114574f41f720a0553222db9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<individual hat?

+1 to typ claim.

On Thu, = Jun 29, 2017 at 5:01 PM, Nat Sakimura <sakimura@gmail.com> = wrote:
Sorry for a tardy= reply, but=C2=A0+1 for the both changes. 'exp' claim requirement i= s a good practical step with a backward compatibility.=C2=A0
Having sai= d that, I believe inferring message types from the existence/absence of a c= laim is not a good security practice. I would like to see an explicit typin= g through "typ" claim added as well.=C2=A0

Nat

On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) <phil.hunt@oracle.com= > wrote:
= Ok.=C2=A0

I spoke with Mike and he will post his changes to SE= T in a new revision over the weekend.=C2=A0
Phil

On Jun 29, 2017, at 1:51 P= M, Dick Hardt <dick.hardt@gmail.com> wrote:

I understand it is new and that there is conte= ntion.=C2=A0

We clearly = want consensus for us to be done with the draft. I think having it in the n= ext draft anchors the discussion so we can discuss and arrive at consensus = or an alternative.=C2=A0

So yes, is like a new draft posted so we can discuss.=C2=A0

On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt <<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om> wrote:
Dick,

The section is a bra= nd new section. It seems to me that has not been any (or limited) discussio= n to warrant putting it in the document.=C2=A0 It certainly came to me as a= surprise.

I think the issue of trust model needs = to be discussed.=C2=A0 It may not belong here at all.

<= div>Please advise.=C2=A0 Do you want it posted in spite of consensus?
=

Phil

Oracle Corporation, Identity Cloud Se= rvices Architect & Standards
@independentid
<= /div>phil.= hunt@oracle.com

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

<= div>Hi Phil

wrt asking for more discussion, I appreciate= you making the suggestion on behalf of the chairs. It does seem there is a= reasonable amount of discussion going on now would you not agree?

I'd like to get the doc updated in time for Prague so = that we have a clear reference point for discussion there and then.

Unclear why you would post a change when it was Mike= that did this work. Am I missing something?

Mike:= would you update the doc with what you think is rough consensus when you h= ave time so that we can have a crisp discussion in Prague?



On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.co= m> wrote:
I agree on the exp part.=C2=A0

Regarding the = second part. I would like to see more discussion.=C2=A0

For example, in the the use cases, there may be compatibility issues i= f different set profiles cannot be sent over the same stream.=C2=A0

Such profiles should avoid things like requiring signing a= nd encryption without consideration regarding how they are transferred.=C2= =A0 Also key management might be better tied up in how the streams are mana= ges because the network relationship may define the requirements rather tha= n the data.=C2=A0

=
My initial reaction is, the profi= les should stick to the data and valid interpretation.=C2=A0

If the = group agrees I will merge the exp and post over the weekend.=C2=A0

I can merge the second part if there is a strong agreement = to do so.=C2=A0

Thanks!

Phil

On Jun 28, 2017, at = 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you Mike for working on this. I'm very = happy with the change regarding the "exp" claim, and believe it i= s the best resolution to the "ID Token" confusion concern.
<= div>
By making the "exp" claim that is already NOT RECOMMENDED in the current draft a MUST NOT, we can prov= ide the ID Tokens and SET uniqueness guarantee that is desired, allowing th= ese two types of JWTs to be used with a common issuer. This also allows &qu= ot;sub" to be used for its intended purpose (as defined by RFC7519) wi= thout modification, which other working groups that wish to profile SET hav= e expressed an interest to do

The benefit the comm= unity will gain from the SET standard overall is a standard way to express = events that won't conflict with ID Token (no "iss" partitioni= ng required). With Mike's changes we achieve that, and in a way that re= tains the original simplicity, extensibility and generalizability goals of = SET by not redefining any of JWT's standard claims.


On Wed, Ju= n 28, 2017 at 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi folks,

=C2=A0=

I wanted to give you a heads-up about two SE= T spec updates in the current editor=E2=80=99s draft before they are publis= hed.

=C2=A0

The first solves the potential ID Token / SET confusion pr= oblem by requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D = claim when ID Tokens could also be generated by the same issuer.=C2=A0 Beca= use =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.=C2=A0 Note tha= t this solution is already recommended in the specification.=C2=A0 The edit= or=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provide= s a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

=C2=A0

The second adds the following new section:<= u>

=C2=A0

<= a>Requirements for SET Profiles=

<= u>=C2=A0

P= rofile Specifications for SETs define the syntax and semantics of SETs conf= orming to that SET profile and rules for validating those SETs. The syntax = defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

<= u>=C2=A0

D= efining the semantics of the SET contents for SETs utilizing the profile is= equally important. Possibly most important is defining the procedures used= to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's= keys that uses the iss claim value as its input.

<= u>=C2=A0

P= rofile Specifications MUST clearly specify the steps that a recipient of a = SET utilizing that profile MUST perform to validate that the SET is both sy= ntactically and semantically valid.

=C2=A0

It=E2=80=99s included to inform profile writers= about what they must do to be able to use SETs securely.=C2=A0 While much = of the discussion as of late has been about syntax, semantics is equally im= portant, and must be considered by profile writers and deployers.

=C2=A0

I believe that the new section contains only statem= ents that are already factually accurate requirements but that were previou= sly unstated.=C2=A0 The editor=E2=80=99s draft makes these requirements exp= licit.=C2=A0 Feedback on how to make these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best w= ishes,

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

=C2=A0


=

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
Sub= scribe to the HARDTWARE mail list to lea= rn about projects I am working on!
_______________________________________________
Id-event mailing li= st
Id-event@ietf.= org
--
=
Subscribe to the HARDT= WARE mail list to learn about projects I am working on!
_____________________________________________= __
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--

Nat Sakimura

Chairman of the Board, OpenID Foundation




--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
--001a114574f41f720a0553222db9-- From nobody Thu Jun 29 17:17:36 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CCD1243FE for ; Thu, 29 Jun 2017 17:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx_LHLG90uWD for ; Thu, 29 Jun 2017 17:17:31 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3451200F3 for ; Thu, 29 Jun 2017 17:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VfARVVvP5XuklvyYEo+Tfaj4Y4P4QBjozEBA3fkSX6U=; b=HjOqy3MyTq5na0RhidIsqMB6nHWfTyHVTa+OeCY41tbKOqd1x9ql2YmJgnWclAONzDOS0q1WB37pDs+mQ7CPt/ZGHS4/gMYxJejd2N11W+OegqSolaiVkwWaWGZYe3DUnDsJ1YyGB27X0iJAsJukfB0pJqwGJko4vPY2jY5TD2o= Received: from DM5PR21MB0505.namprd21.prod.outlook.com (10.172.91.139) by DM5PR21MB0475.namprd21.prod.outlook.com (10.172.92.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.3; Fri, 30 Jun 2017 00:17:29 +0000 Received: from DM5PR21MB0505.namprd21.prod.outlook.com ([10.172.91.139]) by DM5PR21MB0505.namprd21.prod.outlook.com ([10.172.91.139]) with mapi id 15.01.1240.005; Fri, 30 Jun 2017 00:17:28 +0000 From: Mike Jones To: Marius Scurtescu , Dick Hardt CC: Yaron Sheffer , SecEvent , Justin Richer , "Phil Hunt (IDM)" Thread-Topic: [Id-event] Use case document Thread-Index: AQHSxGCO0M8YepGkN0WiGw4A72pQEqHjPeqAgAAEBICAAAJOAIAAAdKAgABW7wCAAF6/AIAAUMmAgAAzJoCAKtHwgIAAAxqAgAAOCgCALXctAIAACZQA Date: Fri, 30 Jun 2017 00:17:28 +0000 Message-ID: References: <2104A459-8402-4498-9F7F-3EED264DB4E8@oracle.com> <2F79A80F-AE98-4372-B096-C26ED77F4C3B@mit.edu> <10de4c6f-c0a7-9d9f-c524-fa87048dd580@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-29T17:17:25.0343041-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::71c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0475; 7:lI0oxnzmOa5fAovWLMKRUIUg4uqkZvk56EU5ektuMdrYqIL9xbpEHHcW3ThUZ3EGZFom9WVoI43f0rQ8CrA10UeRj2PucYwVWQjJGQX5er4YD27xC2HnPibpP0BiNqr8gOCARl6ByM3qGXoW90UFDrGSdzpTC16ALhM69GJfDFhNGejBBMCarn6zyG65FfnLQfbq5tJnB8Xvvwy6P6DLedD06YEAbtAxY3+hJbE4AWZe8QZEoQUWkRyDSGrfiYppLUgwaW32CY76uj/ALFcF/j7IBWz90tPTqjADhWpe9gOUAyeNckR4x97ToTg/ydBHlqcrWuLS7BU1MraSFR7SpeHhfPm20PJNXLr3LK+P1/8RacLUM2e32C6gsGBweH0Qfv01mCHKLzNMO+H+ohZ3/rehZNjiUYuhtJXGcZNugglmj12FVAshbpdSptl0T9vldIythEvnnVIYKqMw3SKLVi85+teBvsuSVkdLniGdE0ANAeEyLu/IChwBe2/lBjB2Z6Pc2yuS9ABtZz0jmE2l7ZAJ79/1lmoyIcxpanS4rAsNYXf4xURR/WEe+p2AFdTC7h6XzsAGEsIwHAHnulPvYC7uZMOe6CGojOoU2fhJ0a6GmZUGyLoK18akQCm4e2zchpGHviO4AvyR8EtiKlMzrmPZh6sE9Dtz7YngNI11pKMKdxzG4XU1Jxyay1H1kJMTYdVcZZTw32euPP7yH/t3DVVwDSCzMQpw19eO8IYeg7TKyx03WJIHIzrQe60jS6+HL/qMnCxLC2bf9WJ5r0Il4/ubPq+7nVdIPrIl1Zn2rtt9vQQU7jd1gpdfU2RlOWqg x-ms-office365-filtering-correlation-id: edf57ffc-dbe5-4578-955b-08d4bf4d647a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR21MB0475; x-ms-traffictypediagnostic: DM5PR21MB0475: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(10436049006162)(26388249023172)(236129657087228)(90097320859284)(211936372134217)(148574349560750)(21748063052155)(167848164394848); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910019)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR21MB0475; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR21MB0475; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39840400002)(39400400002)(39850400002)(39410400002)(51694002)(57704003)(377454003)(24454002)(606006)(7066003)(3280700002)(102836003)(2900100001)(3660700001)(93886004)(6246003)(72206003)(2906002)(966005)(6506006)(53936002)(5005710100001)(5660300001)(8990500004)(575784001)(10290500003)(478600001)(33656002)(7696004)(6436002)(2950100002)(86362001)(38730400002)(53376002)(14454004)(86612001)(53546010)(189998001)(39060400002)(81156014)(77096006)(25786009)(4326008)(54356999)(76176999)(236005)(50986999)(19609705001)(6306002)(53946003)(9686003)(54896002)(7736002)(6116002)(229853002)(10090500001)(8936002)(8676002)(55016002)(81166006)(74316002)(790700001)(99286003)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0475; H:DM5PR21MB0505.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB05050666EE59BABF5A2BBE5DF5D30DM5PR21MB0505namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 00:17:28.3818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0475 Archived-At: Subject: Re: [Id-event] Use case document X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:17:35 -0000 --_000_DM5PR21MB05050666EE59BABF5A2BBE5DF5D30DM5PR21MB0505namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VhcmluZyBteSBPcGVuSUQgbWVtYmVyIGhhdCDigJMgd2h5IGlzbuKAmXQgdGhpcyBhIFJJU0Mg d29ya2luZyBncm91cCBkb2N1bWVudCwgcmF0aGVyIHRoYW4gYW4gU0VDRVZFTlQgd29ya2luZyBn cm91cCBkb2N1bWVudD8NCg0KRnJvbTogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyaXVzIFNjdXJ0ZXNjdQ0KU2VudDogVGh1cnNkYXks IEp1bmUgMjksIDIwMTcgNDo0MiBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IFNlY0V2ZW50 IDxpZC1ldmVudEBpZXRmLm9yZz47IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IFBo aWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2 ZW50XSBVc2UgY2FzZSBkb2N1bWVudA0KDQpJIGp1c3Qgc3VibWl0dGVkIHRoZSBSSVNDIHVzZSBj YXNlcyBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY3VydGVzY3Utc2Vj ZXZlbnQtcmlzYy11c2UtY2FzZXMtMDANCg0KSXQgaXMgdmVyeSBiYXNpYyByaWdodCBub3csIEkg anVzdCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUgaXMgYXQgbGVhc3QgYSBiYXNpYyB2 ZXJzaW9uIHN1Ym1pdHRlZCBiZWZvcmUgdGhlIGRlYWRsaW5lLg0KDQpJIHdpbGwgZXhwYW5kIHRo ZSBkZXNjcmlwdGlvbnMgYW5kIGFkZCBkaWFncmFtcy4NCg0KTGV0IG1lIGtub3cgaWYgYW55b25l IGVsc2Ugd291bGQgbGlrZSB0byBiZSBhbiBhdXRob3IuDQoNCk1hcml1cw0KDQoNCk1hcml1cw0K DQpPbiBXZWQsIE1heSAzMSwgMjAxNyBhdCA2OjI0IFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0 QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkFncmVlZC4g VGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIHRoZXNlIHRvIGJlIGluIHRoZSBzYW1lIGRvY3Vt ZW50Lg0KDQpPbiBXZWQsIE1heSAzMSwgMjAxNyBhdCA1OjMzIFBNLCBQaGlsIEh1bnQgKElETSkg PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3Rl Og0KTWFyaXVzLA0KDQpHbyBhaGVhZCBhbiBzdWJtaXQgYXMgYW4gaW5kaXZpZHVhbCBkcmFmdC4g SSB3aWxsIHN1Ym1pdCBzY2ltIGNhc2VzIGluIGEgc2VwYXJhdGUgZHJhZnQuDQoNCkFmYWlrIHRo ZXJlIGlzIG5vIHBsYW4gdG8gaGF2ZSB0aGlzIGhlIGEgc2luZ2xlIHdnIGRvY3VtZW50Lg0KDQpQ aGlsDQoNCk9uIE1heSAzMSwgMjAxNywgYXQgOToyMiBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNj dXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+PiB3cm90ZToN CkhlcmUgaXMgYW4gaW5pdGlhbCB1c2UgY2FzZSBkb2N1bWVudCwgZm9yIG5vdyBpdCBoYXMgb25s eSB0aGUgUklTQyB1c2UgY2FzZXMgd2UgZGlzY3Vzc2VkIHNvIGZhci4gV2hlbiBQaGlsIGdldHMg YmFjayBJIHdpbGwgY29vcmRpbmF0ZSB3aXRoIGhpbSB0byBhZGQgU0NJTSB1c2UgY2FzZXMgdG8g dGhpcyBzYW1lIEktRC4gSSB3aWxsIGdldCB0aGlzIGludG8gYSBkZWNlbnQgc2hhcGUgZm9yIHRo ZSBJRVRGIG1lZXRpbmcuDQoNCk1hcml1cw0KDQpPbiBUaHUsIE1heSA0LCAyMDE3IGF0IDExOjI4 IEFNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5p ZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpXaGF0ZXZlciB3b3JrcyBmb3IgeW91IC0gYW5kIHRo YXQncyB0aGUgd2hvbGUgcG9pbnQgb2YgKmluZGl2aWR1YWwqIEktRHMuDQoNClRoYW5rcywNCg0K ICAgIFlhcm9uDQoNCk9uIDA0LzA1LzE3IDE4OjI1LCBNYXJpdXMgU2N1cnRlc2N1IHdyb3RlOg0K RG8gd2UgbmVlZCBvbmUgZG9jdW1lbnQgZm9yIGFsbCB1c2UgY2FzZXMgKGFsbCBwcm9maWxlcykg b3Igb25lIGZvciBlYWNoIHByb2ZpbGVzPw0KDQpJIGFtIGhhcHB5IHRvIGNyZWF0ZSB0aGUgb25l IGRvY3VtZW50IG9yIHRoZSBvbmUgZm9yIFJJU0MgKGlmIG9uZSBwZXIgcHJvZmlsZSkuDQoNCk1h cml1cw0KDQpPbiBUaHUsIE1heSA0LCAyMDE3IGF0IDM6MzYgQU0sIFlhcm9uIFNoZWZmZXIgPHlh cm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6 DQoNCk15IHN0cm9uZyBwcmVmZXJlbmNlIHdvdWxkIGJlIGFuIGluZGl2aWR1YWwgSS1EIHRoYXQg KGFzIEp1c3RpbiBzYXlzKSB3aWxsIE5PVCBiZSBwdXNoZWQgdG8gUkZDLiBXaHkgYW4gSS1EIGF0 IGFsbD8gQmVjYXVzZSB0aGlzIGlzIHdoYXQgSUVURiBmb2xrcyBhcmUgdXNlZCB0bywgYW5kIGl0 IGlzIHJlZmVyZW5jZWQgZnJvbSB0aGUgV0cgYWdlbmRhIGFuZCBtaW51dGVzLg0KDQpUaGFua3Ms DQoNCiAgICBZYXJvbg0KDQpPbiAwNC8wNS8xNyAwNzo1NywgSnVzdGluIFJpY2hlciB3cm90ZToN CkluIGZhY3QsIEnigJltIGdvaW5nIHRvIGFzayB0aGF0IHdlICpub3QqIHB1c2ggYSB1c2UgY2Fz ZXMgZG9jdW1lbnQgdG93YXJkIFJGQy4gVXNlIGNhc2UgZG9jdW1lbnRzIGFyZSB3b25kZXJmdWwg dG9vbHMgZm9yIGd1aWRpbmcgZGV2ZWxvcG1lbnQsIGJ1dCBzaG91bGQgYmUgZGlzY2FyZGVkIGFz IGFydGlmYWN0cyBvZiB0aGF0IHByb2Nlc3Mgb25jZSBzYWlkIHByb2Nlc3MgaXMgY29tcGxldGVk IChvciBldmVuIHdlbGwgb24gaXRzIHdheSkuDQoNCkFzIHN1Y2gsIFJGQywgd2lraSwgYmxvZyBw b3N0LCBvciBhbnl0aGluZyByZWZlcmVuY2VkIGZyb20gdGhlIGxpc3QgYW5kIGVhc2lseSBmaW5k YWJsZSB3b3Jrcy4NCg0KIOKAlCBKdXN0aW4NCg0KT24gTWF5IDMsIDIwMTcsIGF0IDQ6NDUgUE0s IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbT4+IHdyb3RlOg0KDQpBcyB0aGUgbW9yZSBleHBlcmllbmNlZCBjaGFpciwgSSB3aWxsIGRl ZmVyIHRvIFlhcm9uIGZvciBndWlkYW5jZS4NCg0KU28gZmFyIG5vIG9uZSBoYXMgZXhwZWN0ZWQg aXQgdG8gYmUgYWRvcHRlZCBhcyBhbiBSRkMNCg0KT24gV2VkLCBNYXkgMywgMjAxNyBhdCA0OjM5 IFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT4+IHdyb3RlOg0KRGVwZW5kcyBvbiB3aGF0IHRoZSBXRyB3YW50cy4NCg0KRW1haWwg Y2FzZXMsDQpHaXRodWIgcG9zdGVkIGRvY3VtZW50LA0KSW5kaXZpZHVhbCBJRHMgcG9zdGVkIHRv IHRoZSB3b3JraW5nIGdyb3VwLCBvcg0KYW4gSUQgdGhhdCBnZXRzIGFkb3B0ZWQgYXMgYSBXRyBk cmFmdCB0byBlbmQgdXAgYXMgUkZDIChlLmcuIEpPU0UgaGFzIFJGQzcxNjUsIGFuZCBTQ0lNIGl0 c2VsZiBoYWQgUkZDNzY0MiwgT2F1dGggaGFkIGEgV0cgZHJhZnQgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAzPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9k cmFmdC0yRGlldGYtMkRvYXV0aC0yRHVzZS0yRGNhc2VzLTJEMDMmZD1Ed01GYVEmYz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lU U2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPWd3R0l0cnFReW5scjg2elhHdFduUi1MV3JjcmNU UzZMeTF3MTR5RG8wdmsmcz1fdDRHUkRQYUNNbnMxalc2NDB1TU5vX281QkhIOGtKQ0NRWFVUTGk5 UWFrJmU9PikuDQoNCkxldCB1cyBrbm93IHdoYXQgZm9ybSBhbmQgd2hhdCBmb3JtYXQuDQoNCldl IGNhbiBhbHNvIHVzZSBvbmUgZm9yIE9wZW5JRCBCYWNrY2hhbm5lbCBMb2dvdXQuICBUaGlzIGlz IHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgYmVjYXVzZSBpdCB3aWxsIGJlIHRyaWdnZXJlZCBieSAo b3IgaXMgcmVsYXRlZCB0bykgU0NJTSBhbmQgYnkgUklTQyBldmVudHMgc3VjaCBhcyBhY2NvdW50 IHJlc2V0cywgYXV0aGVudGljYXRpb24gZmFjdG9yIGNoYW5nZXMgZXRjLg0KDQpQaGlsDQoNCk9y YWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0ICYgU3Rh bmRhcmRzDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRp ZC5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1nd0dJ dHJxUXlubHI4NnpYR3RXblItTFdyY3JjVFM2THkxdzE0eURvMHZrJnM9NXJLWG52N0dZdnZzSjVo dVBtb0dJM1BwUDg1ZlVuUVpycktCeXpiYm1ZQSZlPT4NCnBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gTWF5IDMsIDIwMTcsIGF0IDQ6MzEgUE0s IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbT4+IHdyb3RlOg0KDQpIaSBQaGlsDQoNCnBlcg0KDQpodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL2lkLWV2ZW50L0ZHdXo5SXNVTUtxS2VxMk9qRUJqQ1o5Y0JjSTxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNo aXZlLmlldGYub3JnX2FyY2hfbXNnX2lkLTJEZXZlbnRfRkd1ejlJc1VNS3FLZXEyT2pFQmpDWjlj QmNJJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1iQUkySDY2 MWExUWtJdGZwbHJkM1JJTTM2ZGdBaEY0V2RiV3hXOEJPeTRRJnM9ZWJocWdkd0JmbWNsRnBWbi1j U2NENnVvaVlxa21aVmxScEMzWFhrOTFFcyZlPT4NCg0KeW91IG9mZmVyZWQgdG8gcHV0IHRoZW0g aW4gYSBXRyBkb2MgKHNlZSBxdWF0ZSBiZWxvdykuIFdvdWxkIHRoYXQgbm90IGJlIGFuIElELiBB bHNvLCBhcyBJIHJlYWQgb3ZlciB0aGUgZG9jdW1lbnQsIGl0IGlzIGhhcmQgdG8gZm9sbG93IHdo YXQgdGhlIHVzZSBjYXNlcyBhcmUgYXMgaXQgaXMgdmVyeSB2ZXJib3NlLg0KDQoNCk9uIFR1ZSwg QXByIDE4LCAyMDE3IGF0IDExOjI3IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q+OyB3cm90ZToNCg0KDQoNCj4gQWxsLA0K DQo+DQoNCj4gRGljayBhc2tlZCBtZSBpZiBJIHdvdWxkIGVudW1lcmF0ZSB0aGUgU0NJTSB1c2Ug Y2FzZXMuICBIZXJlIGlzIHRoZSBTQ0lNDQoNCj4gY2FzZS4gSGFwcHkgdG8gcHV0IHRoZXNlIHNv bWV3aGVyZSBpbiBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCk9uIFdlZCwgTWF5IDMsIDIw MTcgYXQgNDoxNiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCk15IHVuZGVyc3RhbmRpbmcgd2FzIHlvdSB3YW50 ZWQgaW5mb3JtYWwgY2FzZXMgbm90IElEcy4gVGhlIFNDSU0gY2FzZXMgaGF2ZSBiZWVuIHBvc3Rl ZCB0byB0aGUgbWFpbGluZyBsaXN0LiBJIGJlbGlldmUgTWFyaXVzIGlzIGNsb3NlIG9uIHRoZSBS SVNDIGNhc2VzLg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQg U2VydmljZXMgQXJjaGl0ZWN0ICYgU3RhbmRhcmRzDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVw ZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZtPWJBSTJINjYxYTFRa0l0ZnBscmQzUklNMzZkZ0FoRjRXZGJXeFc4 Qk95NFEmcz1uQk5PM19kX013NGVucFU1NFZ4dVRjb3FDSlNYa1NTemc4TG5YSWtJNWJnJmU9Pg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpPbiBN YXkgMywgMjAxNywgYXQgMzo1NiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208 bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNClBoaWwgLyBNYXJpdXMNCg0K QXQgdGhlIENoaWNhZ28gbWVldGluZywgdGhlIHR3byBvZiB5b3UgYWdyZWVkIHRvIHdvcmsgb24g YSBkb2N1bWVudCBjb250YWluaW5nIHVzZSBjYXNlcyB5b3UgY29uc2lkZXJlZCB0byBiZSByZWxl dmFudCBmb3Igc2VjZXZlbnQgc28gdGhhdCB0aGUgV0cgY291bGQgZGVjaWRlIHdoaWNoIG9uZXMg d2VyZSBpbiBzY29wZSBhbmQgd2hpY2ggb25lcyB3ZXJlIG91dCBvZiBzY29wZS4NCg0KQ2hlY2tp bmcgaW4gb24gdGhlIHN0YXR1cyBvZiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQuIFdvdWxkIHlvdSBw cm92aWRlIGFuIHVwZGF0ZSB3aGVuIHlvdSBoYXZlIGEgY2hhbmNlPw0KDQovRGljaw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFp bGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hD Z2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VH SnhQRWl2empXd2xOS2U0Q19sTElHayZtPUhXZHk0UTlmSEFZQjNmLURaMkdXVUpuYVpER2NaUVJh TWV4QzJvSHVSN2cmcz1KVHdDeGJYUHpZX0E2MklpeXdUTUlqUkItWHNNWThVUGFmQnM0b1B3T1Rj JmU9DQoNCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhlIEhBUkRUV0FSRTxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1E d01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJt NWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPWJBSTJINjYxYTFRa0l0 ZnBscmQzUklNMzZkZ0FoRjRXZGJXeFc4Qk95NFEmcz11VnN0ZDlSMF8xVUNkSjZzX3JjWDd4aFlv NmZ5R3VrMjJBUGtpd0wwdnBJJmU9PiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQgcHJvamVjdHMg SSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZy PUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1iQUkySDY2MWEx UWtJdGZwbHJkM1JJTTM2ZGdBaEY0V2RiV3hXOEJPeTRRJnM9ZnprWFlLYTdsOXZQYzJWcnBEZWFC Wm83Ykg5Y0Ryazl3VWV0aFZidUNTOCZlPQ0KDQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBI QVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smbT1nd0dJdHJxUXlubHI4NnpYR3RXblItTFdyY3JjVFM2THkxdzE0eURvMHZrJnM9dmxq YXFlRVFGY0R3c2lfek5PNVIydWVjTHYyQjNWRThRdmRFVkJSSElHSSZlPT4gbWFpbCBsaXN0IHRv IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklk LWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pZC0yRGV2ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm bT1nd0dJdHJxUXlubHI4NnpYR3RXblItTFdyY3JjVFM2THkxdzE0eURvMHZrJnM9dDVlM0l2Wl9l LUtSSFVCVk1manR3S0VzNzR5TFp2YTR6LTZPa2tnbVNqbyZlPT4NCg0KDQoNCg0KDQo8ZHJhZnQt c2N1cnRlc2N1LXNlY2V2ZW50LXVzZS1jYXNlcy50eHQ+DQo8ZHJhZnQtc2N1cnRlc2N1LXNlY2V2 ZW50LXVzZS1jYXNlcy5wZGY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPWd3R0l0cnFR eW5scjg2elhHdFduUi1MV3JjcmNUUzZMeTF3MTR5RG8wdmsmcz10NWUzSXZaX2UtS1JIVUJWTWZq dHdLRXM3NHlMWnZhNHotNk9ra2dtU2pvJmU9DQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBI QVJEVFdBUkU8aHR0cDovL2hhcmR0d2FyZS5jb20vPiBtYWlsIGxpc3QgdG8gbGVhcm4gYWJvdXQg cHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KDQo= --_000_DM5PR21MB05050666EE59BABF5A2BBE5DF5D30DM5PR21MB0505namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4ubTY0MDY2OTQ5Nzc5OTg2MTc2OG0tMTI4MTMxNjkzOTg3NjM5NTQ5MW00NDMyMjg4NDg0NjI2 OTMzNjA2bS05NjkxMDIxNzIxMDYxOTgyMzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0 eWxlLW5hbWU6bV82NDA2Njk0OTc3OTk4NjE3NjhtXy0xMjgxMzE2OTM5ODc2Mzk1NDkxbV80NDMy Mjg4NDg0NjI2OTMzNjA2bV8tOTY5MTAyMTcyMTA2MTk4MjM3YXBwbGUtY29udmVydGVkLXNwYWNl O30NCnNwYW4ubTY0MDY2OTQ5Nzc5OTg2MTc2OG0tMTI4MTMxNjkzOTg3NjM5NTQ5MW00NDMyMjg4 NDg0NjI2OTMzNjA2bS05NjkxMDIxNzIxMDYxOTgyMzdtMTM5MDUwNjY4NTQzMDg1MDgyMmFwcGxl LXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6bV82NDA2Njk0OTc3OTk4NjE3NjhtXy0xMjgx MzE2OTM5ODc2Mzk1NDkxbV80NDMyMjg4NDg0NjI2OTMzNjA2bV8tOTY5MTAyMTcyMTA2MTk4MjM3 bV8xMzkwNTA2Njg1NDMwODUwODIyYXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLm02NDA2Njk0OTc3OTk4NjE3NjhtLTEy ODEzMTY5Mzk4NzYzOTU0OTFtNDQzMjI4ODQ4NDYyNjkzMzYwNm0tOTY5MTAyMTcyMTA2MTk4MjM3 bTEzOTA1MDY2ODU0MzA4NTA4MjJtODM5MzQ2ODg5NTkzODI5MDMwMWFwcGxlLXN0eWxlLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6bV82NDA2Njk0OTc3OTk4NjE3NjhtXy0xMjgxMzE2OTM5ODc2Mzk1 NDkxbV80NDMyMjg4NDg0NjI2OTMzNjA2bV8tOTY5MTAyMTcyMTA2MTk4MjM3bV8xMzkwNTA2Njg1 NDMwODUwODIybV84MzkzNDY4ODk1OTM4MjkwMzAxYXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPldlYXJpbmcgbXkgT3BlbklE IG1lbWJlciBoYXQg4oCTIHdoeSBpc27igJl0IHRoaXMgYSBSSVNDIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQsIHJhdGhlciB0aGFuIGFuIFNFQ0VWRU5UIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWQtZXZlbnQgW21h aWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSA8Yj4NCk9uIEJlaGFsZiBPZiA8L2I+TWFy aXVzIFNjdXJ0ZXNjdTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAyOSwgMjAxNyA0 OjQyIFBNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWls LmNvbSZndDs7IFNlY0V2ZW50ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs7IEp1c3RpbiBSaWNo ZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs7IFBoaWwgSHVudCAoSURNKSAmbHQ7cGhpbC5odW50 QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIFVzZSBj YXNlIGRvY3VtZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3Qgc3VibWl0 dGVkIHRoZSBSSVNDIHVzZSBjYXNlcyBhdDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2N1cnRlc2N1LXNlY2V2ZW50LXJpc2MtdXNlLWNhc2VzLTAwIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2N1cnRlc2N1LXNlY2V2ZW50LXJpc2MtdXNlLWNhc2VzLTAwPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBp cyB2ZXJ5IGJhc2ljIHJpZ2h0IG5vdywgSSBqdXN0IHdhbnRlZCB0byBtYWtlIHN1cmUgdGhhdCB0 aGVyZSBpcyBhdCBsZWFzdCBhIGJhc2ljIHZlcnNpb24gc3VibWl0dGVkIGJlZm9yZSB0aGUgZGVh ZGxpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgd2lsbCBleHBhbmQgdGhlIGRlc2NyaXB0aW9ucyBhbmQgYWRkIGRpYWdyYW1zLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgbWUg a25vdyBpZiBhbnlvbmUgZWxzZSB3b3VsZCBsaWtlIHRvIGJlIGFuIGF1dGhvci48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyaXVzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1hcml1czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFdlZCwgTWF5IDMxLCAyMDE3IGF0IDY6MjQgUE0sIERpY2sgSGFyZHQgJmx0 OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRp Y2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZC4gVGhlcmUgaXMgbm8gcmVx dWlyZW1lbnQgZm9yIHRoZXNlIHRvIGJlIGluIHRoZSBzYW1lIGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgMzEsIDIwMTcg YXQgNTozMyBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJpdXMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1fNjQwNjY5NDk3Nzk5ODYxNzY4bV8tMTI4MTMxNjkzOTg3NjM5NTQ5MUFw cGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV82NDA2Njk0OTc3OTk4NjE3NjhtXy0xMjgxMzE2OTM5 ODc2Mzk1NDkxQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvIGFo ZWFkIGFuIHN1Ym1pdCBhcyBhbiBpbmRpdmlkdWFsIGRyYWZ0LiBJIHdpbGwgc3VibWl0IHNjaW0g Y2FzZXMgaW4gYSBzZXBhcmF0ZSBkcmFmdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0ibV82NDA2Njk0OTc3OTk4NjE3NjhtXy0xMjgxMzE2OTM5ODc2Mzk1NDkxQXBwbGVN YWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzY0MDY2OTQ5Nzc5OTg2MTc2OG1fLTEyODEzMTY5Mzk4NzYz OTU0OTFBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZhaWsgdGhl cmUgaXMgbm8gcGxhbiB0byBoYXZlIHRoaXMgaGUgYSBzaW5nbGUgd2cgZG9jdW1lbnQuJm5ic3A7 PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCk9uIE1heSAzMSwgMjAxNywgYXQgOToyMiBQTSwgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1zY3Vy dGVzY3VAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyBhbiBpbml0aWFsIHVz ZSBjYXNlIGRvY3VtZW50LCBmb3Igbm93IGl0IGhhcyBvbmx5IHRoZSBSSVNDIHVzZSBjYXNlcyB3 ZSBkaXNjdXNzZWQgc28gZmFyLiBXaGVuIFBoaWwgZ2V0cyBiYWNrIEkgd2lsbCBjb29yZGluYXRl IHdpdGggaGltIHRvIGFkZCBTQ0lNIHVzZSBjYXNlcyB0byB0aGlzIHNhbWUgSS1ELiBJIHdpbGwg Z2V0IHRoaXMgaW50byBhIGRlY2VudCBzaGFwZSBmb3IgdGhlIElFVEYgbWVldGluZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0i YWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIE1heSA0LCAyMDE3IGF0IDExOjI4IEFNLCBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVm PSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmll dGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxwPldoYXRldmVyIHdvcmtzIGZvciB5b3UgLSBhbmQgdGhhdCdzIHRoZSB3aG9sZSBw b2ludCBvZiAqaW5kaXZpZHVhbCogSS1Ecy4gPG86cD4NCjwvbzpwPjwvcD4NCjxwPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBZYXJvbjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNC8wNS8xNyAxODoyNSwgTWFyaXVz IFNjdXJ0ZXNjdSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RG8gd2UgbmVlZCBvbmUgZG9jdW1lbnQgZm9yIGFsbCB1c2UgY2FzZXMg KGFsbCBwcm9maWxlcykgb3Igb25lIGZvciBlYWNoIHByb2ZpbGVzPw0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGhhcHB5IHRvIGNyZWF0ZSB0aGUg b25lIGRvY3VtZW50IG9yIHRoZSBvbmUgZm9yIFJJU0MgKGlmIG9uZSBwZXIgcHJvZmlsZSkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NYXJpdXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUaHUsIE1heSA0LCAyMDE3IGF0IDM6MzYgQU0sIFlhcm9uIFNoZWZmZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPHA+TXkgc3Ryb25nIHByZWZlcmVuY2Ugd291bGQgYmUgYW4gaW5k aXZpZHVhbCBJLUQgdGhhdCAoYXMgSnVzdGluIHNheXMpIHdpbGwgTk9UIGJlIHB1c2hlZCB0byBS RkMuIFdoeSBhbiBJLUQgYXQgYWxsPyBCZWNhdXNlIHRoaXMgaXMgd2hhdCBJRVRGIGZvbGtzIGFy ZSB1c2VkIHRvLCBhbmQgaXQgaXMgcmVmZXJlbmNlZCBmcm9tIHRoZSBXRyBhZ2VuZGEgYW5kIG1p bnV0ZXMuPG86cD48L286cD48L3A+DQo8cD5UaGFua3MsPG86cD48L286cD48L3A+DQo8cD4mbmJz cDsmbmJzcDsmbmJzcDsgWWFyb248bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gMDQvMDUvMTcgMDc6NTcsIEp1c3RpbiBSaWNoZXIgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZmFjdCwgSeKAmW0gZ29p bmcgdG8gYXNrIHRoYXQgd2UgKm5vdCogcHVzaCBhIHVzZSBjYXNlcyBkb2N1bWVudCB0b3dhcmQg UkZDLiBVc2UgY2FzZSBkb2N1bWVudHMgYXJlIHdvbmRlcmZ1bCB0b29scyBmb3IgZ3VpZGluZyBk ZXZlbG9wbWVudCwgYnV0IHNob3VsZCBiZSBkaXNjYXJkZWQgYXMgYXJ0aWZhY3RzIG9mIHRoYXQg cHJvY2VzcyBvbmNlIHNhaWQgcHJvY2VzcyBpcyBjb21wbGV0ZWQgKG9yIGV2ZW4gd2VsbA0KIG9u IGl0cyB3YXkpLiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIHN1Y2gsIFJGQywgd2lraSwgYmxvZyBwb3N0LCBvciBhbnl0aGluZyByZWZlcmVuY2VkIGZy b20gdGhlIGxpc3QgYW5kIGVhc2lseSBmaW5kYWJsZSB3b3Jrcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWF5 IDMsIDIwMTcsIGF0IDQ6NDUgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5BcyB0aGUgbW9yZSBleHBlcmllbmNlZCBjaGFpciwgSSB3aWxs IGRlZmVyIHRvIFlhcm9uIGZvciBndWlkYW5jZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5TbyBmYXIgbm8gb25lIGhhcyBleHBlY3RlZCBpdCB0byBiZSBhZG9wdGVk IGFzIGFuIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pk9uIFdlZCwgTWF5IDMsIDIwMTcgYXQgNDozOSBQTSwgUGhpbCBIdW50PHNwYW4gY2xhc3M9Im02 NDA2Njk0OTc3OTk4NjE3NjhtLTEyODEzMTY5Mzk4NzYzOTU0OTFtNDQzMjI4ODQ4NDYyNjkzMzYw Nm0tOTY5MTAyMTcyMTA2MTk4MjM3YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ Jmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8c3BhbiBjbGFzcz0ibTY0MDY2OTQ5Nzc5OTg2 MTc2OG0tMTI4MTMxNjkzOTg3NjM5NTQ5MW00NDMyMjg4NDg0NjI2OTMzNjA2bS05NjkxMDIxNzIx MDYxOTgyMzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5EZXBlbmRzIG9uIHdoYXQgdGhlIFdHIHdhbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkVtYWlsIGNhc2Vz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkdpdGh1YiBwb3N0ZWQgZG9jdW1lbnQsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+SW5kaXZpZHVhbCBJRHMgcG9zdGVkIHRvIHRoZSB3b3JraW5nIGdyb3VwLCBvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPmFuIElEIHRoYXQgZ2V0cyBhZG9wdGVkIGFzIGEgV0cgZHJhZnQg dG8gZW5kIHVwIGFzIFJGQyAoZS5nLiBKT1NFIGhhcyBSRkM3MTY1LCBhbmQgU0NJTSBpdHNlbGYg aGFkIFJGQzc2NDIsIE9hdXRoIGhhZCBhIFdHIGRyYWZ0PHNwYW4gY2xhc3M9Im02NDA2Njk0OTc3 OTk4NjE3NjhtLTEyODEzMTY5Mzk4NzYzOTU0OTFtNDQzMjI4ODQ4NDYyNjkzMzYwNm0tOTY5MTAy MTcyMTA2MTk4MjM3YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29s cy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRG9hdXRoLTJEdXNlLTJEY2FzZXMtMkQwMyZh bXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFt cDttPWd3R0l0cnFReW5scjg2elhHdFduUi1MV3JjcmNUUzZMeTF3MTR5RG8wdmsmYW1wO3M9X3Q0 R1JEUGFDTW5zMWpXNjQwdU1Ob19vNUJISDhrSkNDUVhVVExpOVFhayZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC11c2Ut Y2FzZXMtMDM8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5MZXQgdXMga25vdyB3aGF0IGZvcm0gYW5kIHdoYXQgZm9ybWF0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldlIGNhbiBhbHNvIHVzZSBvbmUgZm9y IE9wZW5JRCBCYWNrY2hhbm5lbCBMb2dvdXQuJm5ic3A7IFRoaXMgaXMgcGFydGljdWxhcmx5IGlt cG9ydGFudCBiZWNhdXNlIGl0IHdpbGwgYmUgdHJpZ2dlcmVkIGJ5IChvciBpcyByZWxhdGVkIHRv KSBTQ0lNIGFuZCBieSBSSVNDIGV2ZW50cyBzdWNoIGFzIGFjY291bnQNCiByZXNldHMsIGF1dGhl bnRpY2F0aW9uIGZhY3RvciBjaGFuZ2VzIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNl cnZpY2VzIEFyY2hpdGVjdCAmYW1wOyBTdGFuZGFyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5AaW5k ZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb21f JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm YW1wO209Z3dHSXRycVF5bmxyODZ6WEd0V25SLUxXcmNyY1RTNkx5MXcxNHlEbzB2ayZhbXA7cz01 cktYbnY3R1l2dnNKNWh1UG1vR0kzUHBQODVmVW5RWnJyS0J5emJibVlBJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+T24gTWF5IDMsIDIwMTcsIGF0IDQ6MzEgUE0sIERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIFBoaWwN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5wZXImbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZl LmlldGYub3JnX2FyY2hfbXNnX2lkLTJEZXZlbnRfRkd1ejlJc1VNS3FLZXEyT2pFQmpDWjljQmNJ JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm YW1wO209YkFJMkg2NjFhMVFrSXRmcGxyZDNSSU0zNmRnQWhGNFdkYld4VzhCT3k0USZhbXA7cz1l YmhxZ2R3QmZtY2xGcFZuLWNTY0Q2dW9pWXFrbVpWbFJwQzNYWGs5MUVzJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaWQtZXZlbnQv Rkd1ejlJc1VNS3FLZXEyT2pFQmpDWjljQmNJPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnlvdSBvZmZlcmVkIHRvIHB1dCB0aGVtIGluIGEgV0cgZG9j IChzZWUgcXVhdGUgYmVsb3cpLiBXb3VsZCB0aGF0IG5vdCBiZSBhbiBJRC4gQWxzbywgYXMgSSBy ZWFkIG92ZXIgdGhlIGRvY3VtZW50LCBpdCBpcyBoYXJkIHRvIGZvbGxvdyB3aGF0IHRoZSB1c2Ug Y2FzZXMgYXJlIGFzIGl0IGlzIHZlcnkNCiB2ZXJib3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny41cHQ7Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpub3JtYWw7 Ym9yZGVyLXRvcC1sZWZ0LXJhZGl1czo0cHg7Ym9yZGVyLXRvcC1yaWdodC1yYWRpdXM6NHB4O2Jv cmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOjRweDtib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOjRw eDt3aGl0ZS1zcGFjZTpwcmUtd3JhcDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+T24gVHVlLCBBcHIgMTgsIDIwMTcgYXQgMTE6 MjcgQU0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t JmFtcDtndCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzM3QUI3Ij5waGls Lmh1bnRAb3JhY2xlLmNvbSZndDs8L3NwYW4+PC9hPjsgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+Jmd0OyBBbGwsPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzMzMzMzMyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjVwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzMiPiZndDsgRGljayBhc2tlZCBt ZSBpZiBJIHdvdWxkIGVudW1lcmF0ZSB0aGUgU0NJTSB1c2UgY2FzZXMuJm5ic3A7IEhlcmUgaXMg dGhlIFNDSU08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny41cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMz Ij4mZ3Q7IGNhc2UuIEhhcHB5IHRvIHB1dCB0aGVzZSBzb21ld2hlcmUgaW4gYSB3b3JraW5nIGdy b3VwIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+T24gV2VkLCBNYXkgMywgMjAxNyBhdCA0OjE2IFBNLCBQaGlsIEh1bnQ8c3BhbiBjbGFz cz0ibTY0MDY2OTQ5Nzc5OTg2MTc2OG0tMTI4MTMxNjkzOTg3NjM5NTQ5MW00NDMyMjg4NDg0NjI2 OTMzNjA2bS05NjkxMDIxNzIxMDYxOTgyMzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3 Nzk5ODYxNzY4bS0xMjgxMzE2OTM5ODc2Mzk1NDkxbTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEw MjE3MjEwNjE5ODIzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgdW5kZXJzdGFuZGluZyB3YXMgeW91IHdhbnRlZCBp bmZvcm1hbCBjYXNlcyBub3QgSURzLiBUaGUgU0NJTSBjYXNlcyBoYXZlIGJlZW4gcG9zdGVkIHRv IHRoZSBtYWlsaW5nIGxpc3QuIEkgYmVsaWV2ZSBNYXJpdXMgaXMgY2xvc2Ugb24gdGhlIFJJU0Mg Y2FzZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UGhpbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PcmFjbGUgQ29ycG9yYXRp b24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdCAmYW1wOyBTdGFuZGFyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193 d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1iQUkySDY2MWExUWtJdGZwbHJkM1JJTTM2ZGdBaEY0 V2RiV3hXOEJPeTRRJmFtcDtzPW5CTk8zX2RfTXc0ZW5wVTU0Vnh1VGNvcUNKU1hrU1N6ZzhMblhJ a0k1YmcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gTWF5IDMsIDIwMTcsIGF0IDM6NTYgUE0s IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPlBoaWwgLyBNYXJpdXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5BdCB0aGUgQ2hpY2FnbyBtZWV0aW5nLCB0aGUgdHdvIG9mIHlvdSBhZ3JlZWQgdG8gd29yayBv biBhIGRvY3VtZW50IGNvbnRhaW5pbmcgdXNlIGNhc2VzIHlvdSBjb25zaWRlcmVkIHRvIGJlIHJl bGV2YW50IGZvciBzZWNldmVudCBzbyB0aGF0IHRoZSBXRyBjb3VsZCBkZWNpZGUgd2hpY2ggb25l cw0KIHdlcmUgaW4gc2NvcGUgYW5kIHdoaWNoIG9uZXMgd2VyZSBvdXQgb2Ygc2NvcGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2hlY2tpbmcgaW4gb24g dGhlIHN0YXR1cyBvZiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQuIFdvdWxkIHlvdSBwcm92aWRlIGFu IHVwZGF0ZSB3aGVuIHlvdSBoYXZlIGEgY2hhbmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi9EaWNrPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUhXZHk0UTlmSEFZQjNmLURaMkdXVUpu YVpER2NaUVJhTWV4QzJvSHVSN2cmYW1wO3M9SlR3Q3hiWFB6WV9BNjJJaXl3VE1JalJCLVhzTVk4 VVBhZkJzNG9Qd09UYyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2 empXd2xOS2U0Q19sTElHayZhbXA7bT1IV2R5NFE5ZkhBWUIzZi1EWjJHV1VKbmFaREdjWlFSYU1l eEMyb0h1UjdnJmFtcDtzPUpUd0N4YlhQellfQTYySWl5d1RNSWpSQi1Yc01ZOFVQYWZCczRvUHdP VGMmYW1wO2U9PC9hPjxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3Nzk5ODYxNzY4bS0xMjgxMzE2OTM5 ODc2Mzk1NDkxbTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEwMjE3MjEwNjE5ODIzN2FwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4tLTxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3Nzk5ODYxNzY4bS0xMjgxMzE2OTM5ODc2Mzk1NDkx bTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEwMjE3MjEwNjE5ODIzN2FwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFzcz0ibTY0MDY2OTQ5Nzc5OTg2MTc2 OG0tMTI4MTMxNjkzOTg3NjM5NTQ5MW00NDMyMjg4NDg0NjI2OTMzNjA2bS05NjkxMDIxNzIxMDYx OTgyMzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNv bV8mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZ MDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElH ayZhbXA7bT1iQUkySDY2MWExUWtJdGZwbHJkM1JJTTM2ZGdBaEY0V2RiV3hXOEJPeTRRJmFtcDtz PXVWc3RkOVIwXzFVQ2RKNnNfcmNYN3hoWW82ZnlHdWsyMkFQa2l3TDB2cEkmYW1wO2U9IiB0YXJn ZXQ9Il9ibGFuayI+SEFSRFRXQVJFPC9hPjxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3Nzk5ODYxNzY4 bS0xMjgxMzE2OTM5ODc2Mzk1NDkxbTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEwMjE3MjEwNjE5 ODIzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxl YXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1 bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NI MEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPWJBSTJINjYxYTFRa0l0ZnBscmQz UklNMzZkZ0FoRjRXZGJXeFc4Qk95NFEmYW1wO3M9ZnprWFlLYTdsOXZQYzJWcnBEZWFCWm83Ykg5 Y0Ryazl3VWV0aFZidUNTOCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQ RWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1iQUkySDY2MWExUWtJdGZwbHJkM1JJTTM2ZGdBaEY0 V2RiV3hXOEJPeTRRJmFtcDtzPWZ6a1hZS2E3bDl2UGMyVnJwRGVhQlpvN2JIOWNEcms5d1VldGhW YnVDUzgmYW1wO2U9PC9hPjxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3Nzk5ODYxNzY4bS0xMjgxMzE2 OTM5ODc2Mzk1NDkxbTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEwMjE3MjEwNjE5ODIzN2FwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4tLTxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3Nzk5ODYxNzY4bS0xMjgxMzE2OTM5ODc2Mzk1 NDkxbTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEwMjE3MjEwNjE5ODIzN2FwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFzcz0ibTY0MDY2OTQ5Nzc5OTg2 MTc2OG0tMTI4MTMxNjkzOTg3NjM5NTQ5MW00NDMyMjg4NDg0NjI2OTMzNjA2bS05NjkxMDIxNzIx MDYxOTgyMzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJl LmNvbV8mYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRw a0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19s TElHayZhbXA7bT1nd0dJdHJxUXlubHI4NnpYR3RXblItTFdyY3JjVFM2THkxdzE0eURvMHZrJmFt cDtzPXZsamFxZUVRRmNEd3NpX3pOTzVSMnVlY0x2MkIzVkU4UXZkRVZCUkhJR0kmYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+SEFSRFRXQVJFPC9hPjxzcGFuIGNsYXNzPSJtNjQwNjY5NDk3Nzk5ODYx NzY4bS0xMjgxMzE2OTM5ODc2Mzk1NDkxbTQ0MzIyODg0ODQ2MjY5MzM2MDZtLTk2OTEwMjE3MjEw NjE5ODIzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRv IGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBs aXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smYW1wO209Z3dHSXRycVF5bmxyODZ6WEd0V25SLUxXcmNyY1RTNkx5 MXcxNHlEbzB2ayZhbXA7cz10NWUzSXZaX2UtS1JIVUJWTWZqdHdLRXM3NHlMWnZhNHotNk9ra2dt U2pvJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmx0O2RyYWZ0LXNjdXJ0ZXNjdS1zZWNldmVudC11c2UtY2FzZXMu dHh0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7ZHJhZnQtc2N1cnRlc2N1LXNlY2V2ZW50LXVzZS1jYXNl cy5wZGYmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209Z3dHSXRycVF5bmxyODZ6WEd0V25SLUxXcmNyY1RTNkx5MXcxNHlEbzB2ayZhbXA7cz10NWUz SXZaX2UtS1JIVUJWTWZqdHdLRXM3NHlMWnZhNHotNk9ra2dtU2pvJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPWd3R0l0cnFR eW5scjg2elhHdFduUi1MV3JjcmNUUzZMeTF3MTR5RG8wdmsmYW1wO3M9dDVlM0l2Wl9lLUtSSFVC Vk1manR3S0VzNzR5TFp2YTR6LTZPa2tnbVNqbyZhbXA7ZT08L2E+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YnNjcmliZSB0byB0aGUgPGEgaHJlZj0iaHR0cDov L2hhcmR0d2FyZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+DQpIQVJEVFdBUkU8L2E+IG1haWwgbGlz dCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_DM5PR21MB05050666EE59BABF5A2BBE5DF5D30DM5PR21MB0505namp_-- From nobody Thu Jun 29 17:18:09 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436511243FE for ; Thu, 29 Jun 2017 17:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr3UNJTCSis2 for ; Thu, 29 Jun 2017 17:18:04 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C57E1200F3 for ; Thu, 29 Jun 2017 17:18:04 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5U0I103001707 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Jun 2017 00:18:01 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v5U0I0iF015313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Jun 2017 00:18:01 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5U0I0s0012127; Fri, 30 Jun 2017 00:18:00 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 17:17:59 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-57E49356-8950-4092-8F6F-BC6E96D22824 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 29 Jun 2017 17:17:57 -0700 Cc: Dick Hardt , William Denniss , Mike Jones , "id-event@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> To: Nat Sakimura X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:18:08 -0000 --Apple-Mail-57E49356-8950-4092-8F6F-BC6E96D22824 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to typ claim.=20 Phil > On Jun 29, 2017, at 5:01 PM, Nat Sakimura wrote: >=20 > Sorry for a tardy reply, but +1 for the both changes. 'exp' claim requirem= ent is a good practical step with a backward compatibility.=20 > Having said that, I believe inferring message types from the existence/abs= ence of a claim is not a good security practice. I would like to see an expl= icit typing through "typ" claim added as well.=20 >=20 > Nat >=20 >> On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) wr= ote: >> Ok.=20 >>=20 >> I spoke with Mike and he will post his changes to SET in a new revision o= ver the weekend.=20 >>=20 >> Phil >>=20 >>> On Jun 29, 2017, at 1:51 PM, Dick Hardt wrote: >>>=20 >>> I understand it is new and that there is contention.=20 >>>=20 >>> We clearly want consensus for us to be done with the draft. I think havi= ng it in the next draft anchors the discussion so we can discuss and arrive a= t consensus or an alternative.=20 >>>=20 >>> So yes, is like a new draft posted so we can discuss.=20 >>>=20 >>>> On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote= : >>>> Dick, >>>>=20 >>>> The section is a brand new section. It seems to me that has not been an= y (or limited) discussion to warrant putting it in the document. It certain= ly came to me as a surprise. >>>>=20 >>>> I think the issue of trust model needs to be discussed. It may not bel= ong here at all. >>>>=20 >>>> Please advise. Do you want it posted in spite of consensus? >>>>=20 >>>> Phil >>>>=20 >>>> Oracle Corporation, Identity Cloud Services Architect & Standards >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>> On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote:= >>>>>=20 >>>>=20 >>>>> Hi Phil >>>>>=20 >>>>> wrt asking for more discussion, I appreciate you making the suggestion= on behalf of the chairs. It does seem there is a reasonable amount of discu= ssion going on now would you not agree? >>>>>=20 >>>>> I'd like to get the doc updated in time for Prague so that we have a c= lear reference point for discussion there and then. >>>>>=20 >>>>> Unclear why you would post a change when it was Mike that did this wor= k. Am I missing something? >>>>>=20 >>>>> Mike: would you update the doc with what you think is rough consensus w= hen you have time so that we can have a crisp discussion in Prague? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) wrote: >>>>>> I agree on the exp part.=20 >>>>>>=20 >>>>>> Regarding the second part. I would like to see more discussion.=20 >>>>>>=20 >>>>>> For example, in the the use cases, there may be compatibility issues i= f different set profiles cannot be sent over the same stream.=20 >>>>>>=20 >>>>>> Such profiles should avoid things like requiring signing and encrypti= on without consideration regarding how they are transferred. Also key manag= ement might be better tied up in how the streams are manages because the net= work relationship may define the requirements rather than the data.=20 >>>>>>=20 >>>>>> My initial reaction is, the profiles should stick to the data and val= id interpretation.=20 >>>>>>=20 >>>>>> If the group agrees I will merge the exp and post over the weekend.=20= >>>>>>=20 >>>>>> I can merge the second part if there is a strong agreement to do so.=20= >>>>>>=20 >>>>>> Thanks! >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>>> On Jun 28, 2017, at 5:24 PM, William Denniss w= rote: >>>>>>>=20 >>>>>>> Thank you Mike for working on this. I'm very happy with the change r= egarding the "exp" claim, and believe it is the best resolution to the "ID T= oken" confusion concern. >>>>>>>=20 >>>>>>> By making the "exp" claim that is already NOT RECOMMENDED in the cur= rent draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guara= ntee that is desired, allowing these two types of JWTs to be used with a com= mon issuer. This also allows "sub" to be used for its intended purpose (as d= efined by RFC7519) without modification, which other working groups that wis= h to profile SET have expressed an interest to do >>>>>>>=20 >>>>>>> The benefit the community will gain from the SET standard overall is= a standard way to express events that won't conflict with ID Token (no "iss= " partitioning required). With Mike's changes we achieve that, and in a way t= hat retains the original simplicity, extensibility and generalizability goal= s of SET by not redefining any of JWT's standard claims. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones wrote: >>>>>>>> Hi folks, >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I wanted to give you a heads-up about two SET spec updates in the c= urrent editor=E2=80=99s draft before they are published. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> The first solves the potential ID Token / SET confusion problem by r= equiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when I= D Tokens could also be generated by the same issuer. Because =E2=80=9Cexp=E2= =80=9D is a required ID Token claim, SETs would therefore be rejected by exi= sting ID Token validation code. Note that this solution is already recommen= ded in the specification. The editor=E2=80=99s draft update makes this solu= tion mandatory. This provides a simple and durable solution to the problem w= e agreed to solve at IETF 98 in Chicago and that has been the subject of muc= h discussion since. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> The second adds the following new section: >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Requirements for SET Profiles >>>>>>>> =20 >>>>>>>> Profile Specifications for SETs define the syntax and semantics of S= ETs conforming to that SET profile and rules for validating those SETs. The s= yntax defined by profiling specifications includes what claims and event pay= load values are used by SETs utilizing the profile. >>>>>>>> =20 >>>>>>>> Defining the semantics of the SET contents for SETs utilizing the p= rofile is equally important. Possibly most important is defining the procedu= res used to validate the SET issuer and to obtain the keys controlled by the= issuer that were used for cryptographic operations used in the JWT represen= ting the SET. For instance, some profiles may define an algorithm for retrie= ving the SET issuer's keys that uses the iss claim value as its input. >>>>>>>> =20 >>>>>>>> Profile Specifications MUST clearly specify the steps that a recipi= ent of a SET utilizing that profile MUST perform to validate that the SET is= both syntactically and semantically valid. >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> It=E2=80=99s included to inform profile writers about what they mus= t do to be able to use SETs securely. While much of the discussion as of la= te has been about syntax, semantics is equally important, and must be consid= ered by profile writers and deployers. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> I believe that the new section contains only statements that are al= ready factually accurate requirements but that were previously unstated. Th= e editor=E2=80=99s draft makes these requirements explicit. Feedback on how= to make these requirements even more clear, is of course, welcomed. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> Bes= t wishes, >>>>>>>>=20 >>>>>>>> -- M= ike >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk= KY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_Ae= S-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Subscribe to the HARDTWARE mail list to learn about projects I am work= ing on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>=20 >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY= 057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZt= YUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE= &e=3D=20 >>>>=20 >>>=20 >>> --=20 >>> Subscribe to the HARDTWARE mail list to learn about projects I am workin= g on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >=20 > --=20 > Nat Sakimura >=20 > Chairman of the Board, OpenID Foundation --Apple-Mail-57E49356-8950-4092-8F6F-BC6E96D22824 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 to typ claim. 

Phil

On Jun 29, 2017, at 5:01 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Sorry for a tardy reply, but +1 f= or the both changes. 'exp' claim requirement is a good practical step with a= backward compatibility. 
Having said that, I believe inferring mes= sage types from the existence/absence of a claim is not a good security prac= tice. I would like to see an explicit typing through "typ" claim added as we= ll. 

Nat

On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Ok. 
<= div id=3D"m_5815899636602158904AppleMailSignature">
I spoke with Mike and he will post his c= hanges to SET in a new revision over the weekend. 

Phil

On Jun 29, 2017, at 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I understan= d it is new and that there is contention. 

<= /div>
We clearly want consensus for us to be done with the d= raft. I think having it in the next draft anchors the discussion so we can d= iscuss and arrive at consensus or an alternative. 

So yes, is like a new draft posted so we can d= iscuss. 

On Thu, Jun 29, 2017 a= t 12:58 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Dick,

The section is a brand new section. It seems to me that has not been any (= or limited) discussion to warrant putting it in the document.  It certa= inly came to me as a surprise.

I think the issue of= trust model needs to be discussed.  It may not belong here at all.

Please advise.  Do you want it posted in spite of= consensus?

<= div>=
Phil

=
Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
phil.hunt@oracle.com

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wro= te:

Hi Phil

wrt asking for more discussion, I appreciate you making the suggestion on= behalf of the chairs. It does seem there is a reasonable amount of discussi= on going on now would you not agree?

I'd like to ge= t the doc updated in time for Prague so that we have a clear reference point= for discussion there and then.

Unclear why yo= u would post a change when it was Mike that did this work. Am I missing some= thing?

Mike: would you update the doc with what you= think is rough consensus when you have time so that we can have a crisp dis= cussion in Prague?



On Wed, Jun 28, 2017 at 5:38= PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I agree on the exp part. 

Regarding the second part. I wou= ld like to see more discussion. 

For example, in the the use cases, there may be compatibility= issues if different set profiles cannot be sent over the same stream. =

Such profiles should a= void things like requiring signing and encryption without consideration rega= rding how they are transferred.  Also key management might be better ti= ed up in how the streams are manages because the network relationship may de= fine the requirements rather than the data. 
My initial reaction is, the profiles should stick= to the data and valid interpretation. 

If the group agrees I wi= ll merge the exp and post over the weekend. 
I can merge the second part if there is a strong a= greement to do so. 


Phil

On Jun 28, 2017, at 5:24 PM, W= illiam Denniss <= wdenniss@google.com> wrote:

Thank you Mike for working on this. I'm very happy with the cha= nge regarding the "exp" claim, and believe it is the best resolution to the "= ID Token" confusion concern.

By making the "exp" cl= aim that is already NOT RECOMMENDED in the current draft a MUST N= OT, we can provide the ID Tokens and SET uniqueness guarantee that is desire= d, allowing these two types of JWTs to be used with a common issuer. This al= so allows "sub" to be used for its intended purpose (as defined by RFC7519) w= ithout modification, which other working groups that wish to profile SET hav= e expressed an interest to do

The benefit the commu= nity will gain from the SET standard overall is a standard way to express ev= ents that won't conflict with ID Token (no "iss" partitioning required). Wit= h Mike's changes we achieve that, and in a way that retains the original sim= plicity, extensibility and generalizability goals of SET by not redefining a= ny of JWT's standard claims.


On Wed, Jun 28, 2017 at 5:08 PM, Mike J= ones <Michael.Jones@microsoft.com> wrote:

Hi folks,

 

I wanted to give you a heads-up about two SET spec updates in the curr= ent editor=E2=80=99s draft before they are published.

 

The first s= olves the potential ID Token / SET confusion problem by requiring that SETs n= ot include a top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also= be generated by the same issuer.  Because =E2=80=9Cexp=E2=80=9D is a r= equired ID Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note that= this solution is already recommended in the specification.  The editor= =E2=80=99s draft update makes this solution mandatory.  This provides a= simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discus= sion since.

 

=

The second adds the following new section:<= /u>

 

Requirements for SET Profiles

 

Pr= ofile Specifications for SETs define the syntax and semantics of SETs confor= ming to that SET profile and rules for validating those SETs. The syntax def= ined by profiling specifications includes what claims and event payload values are used by SE= Ts utilizing the profile.

 

De= fining the semantics of the SET contents for SETs utilizing the profile is e= qually important. Possibly most important is defining the procedures used to= validate the SET issuer and to obtain the keys controlled by the issuer that were used for c= ryptographic operations used in the JWT representing the SET. For instance, s= ome profiles may define an algorithm for retrieving the SET issuer's keys th= at uses the = iss claim value as its input.

 

Pr= ofile Specifications MUST clearly specify the steps that a recipient of a SE= T utilizing that profile MUST perform to validate that the SET is both synta= ctically and semantically valid.

 =

It=E2=80=99s included to inform profile writers a= bout what they must do to be able to use SETs securely.  While much of t= he discussion as of late has been about syntax, semantics is equally importa= nt, and must be considered by profile writers and deployers.

 

=

I believe that the new section contains only statemen= ts that are already factually accurate requirements but that were previously= unstated.  The editor=E2=80=99s draft makes these requirements explici= t.  Feedback on how to make these requirements even more clear, is of course, welcomed.

 

    = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;         Best wishes,

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

=  



_______________________________________________
Id-event mailing list
Id-event@ietf.org=
htt= ps://www.ietf.org/mailman/listinfo/id-event




--
Subscribe to the HARDTWARE mail list to learn about projects I am working o= n!
_______________________________________________
Id-event mailing list
= Id-event@ietf.org=
--
_______________________________________________
= Id-event mailing list
Id-event@ietf.org=
htt= ps://www.ietf.org/mailman/listinfo/id-event
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

= --Apple-Mail-57E49356-8950-4092-8F6F-BC6E96D22824-- From nobody Thu Jun 29 17:20:40 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21E61200F3 for ; Thu, 29 Jun 2017 17:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olnh8mNupHbV for ; Thu, 29 Jun 2017 17:20:35 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D701279EB for ; Thu, 29 Jun 2017 17:20:35 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5U0KVDp003740 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 00:20:32 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5U0KVIK000412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 00:20:31 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5U0KUbR005424; Fri, 30 Jun 2017 00:20:30 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 17:20:30 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-4976D896-9C79-46CF-BD84-579457054D1D Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 29 Jun 2017 17:20:28 -0700 Cc: Dick Hardt , Yaron Sheffer , SecEvent , Justin Richer Content-Transfer-Encoding: 7bit Message-Id: <01231318-9B1C-4814-954F-F52A4EC802D1@oracle.com> References: <2104A459-8402-4498-9F7F-3EED264DB4E8@oracle.com> <2F79A80F-AE98-4372-B096-C26ED77F4C3B@mit.edu> <10de4c6f-c0a7-9d9f-c524-fa87048dd580@gmail.com> To: Marius Scurtescu X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Use case document X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:20:39 -0000 --Apple-Mail-4976D896-9C79-46CF-BD84-579457054D1D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marius Thanks! I plan to publish the SCIM cases as well soon.=20 Phil > On Jun 29, 2017, at 4:42 PM, Marius Scurtescu wrot= e: >=20 > I just submitted the RISC use cases at: > https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases-00 >=20 > It is very basic right now, I just wanted to make sure that there is at le= ast a basic version submitted before the deadline. >=20 > I will expand the descriptions and add diagrams. >=20 > Let me know if anyone else would like to be an author. >=20 > Marius >=20 >=20 > Marius >=20 >> On Wed, May 31, 2017 at 6:24 PM, Dick Hardt wrote:= >> Agreed. There is no requirement for these to be in the same document. >>=20 >>> On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) w= rote: >>=20 >>> Marius, >>>=20 >>> Go ahead an submit as an individual draft. I will submit scim cases in a= separate draft.=20 >>>=20 >>> Afaik there is no plan to have this he a single wg document.=20 >>>=20 >>> Phil >>>=20 >>>> On May 31, 2017, at 9:22 PM, Marius Scurtescu w= rote: >>>>=20 >>>> Here is an initial use case document, for now it has only the RISC use c= ases we discussed so far. When Phil gets back I will coordinate with him to a= dd SCIM use cases to this same I-D. I will get this into a decent shape for t= he IETF meeting. >>>>=20 >>>> Marius >>>>=20 >>>>> On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffer = wrote: >>>>> Whatever works for you - and that's the whole point of *individual* I-= Ds. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Yaron >>>>>=20 >>>>>> On 04/05/17 18:25, Marius Scurtescu wrote: >>>>>> Do we need one document for all use cases (all profiles) or one for e= ach profiles? >>>>>>=20 >>>>>> I am happy to create the one document or the one for RISC (if one per= profile). >>>>>>=20 >>>>>> Marius >>>>>>=20 >>>>>>> On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer wrote: >>>>>>> My strong preference would be an individual I-D that (as Justin says= ) will NOT be pushed to RFC. Why an I-D at all? Because this is what IETF fo= lks are used to, and it is referenced from the WG agenda and minutes. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Yaron >>>>>>>=20 >>>>>>>> On 04/05/17 07:57, Justin Richer wrote: >>>>>>>> In fact, I=E2=80=99m going to ask that we *not* push a use cases do= cument toward RFC. Use case documents are wonderful tools for guiding develo= pment, but should be discarded as artifacts of that process once said proces= s is completed (or even well on its way). >>>>>>>>=20 >>>>>>>> As such, RFC, wiki, blog post, or anything referenced from the list= and easily findable works. >>>>>>>>=20 >>>>>>>> =E2=80=94 Justin >>>>>>>>=20 >>>>>>>>> On May 3, 2017, at 4:45 PM, Dick Hardt wrot= e: >>>>>>>>>=20 >>>>>>>>> As the more experienced chair, I will defer to Yaron for guidance.= >>>>>>>>>=20 >>>>>>>>> So far no one has expected it to be adopted as an RFC >>>>>>>>>=20 >>>>>>>>>> On Wed, May 3, 2017 at 4:39 PM, Phil Hunt w= rote: >>>>>>>>>> Depends on what the WG wants. >>>>>>>>>>=20 >>>>>>>>>> Email cases, >>>>>>>>>> Github posted document, >>>>>>>>>> Individual IDs posted to the working group, or >>>>>>>>>> an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE= has RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft https://tool= s.ietf.org/html/draft-ietf-oauth-use-cases-03). >>>>>>>>>>=20 >>>>>>>>>> Let us know what form and what format. >>>>>>>>>>=20 >>>>>>>>>> We can also use one for OpenID Backchannel Logout. This is parti= cularly important because it will be triggered by (or is related to) SCIM an= d by RISC events such as account resets, authentication factor changes etc. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect & Standards= >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>> On May 3, 2017, at 4:31 PM, Dick Hardt wr= ote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Phil >>>>>>>>>>>=20 >>>>>>>>>>> per=20 >>>>>>>>>>>=20 >>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/id-event/FGuz9IsUMKqKeq2Oj= EBjCZ9cBcI >>>>>>>>>>>=20 >>>>>>>>>>> you offered to put them in a WG doc (see quate below). Would tha= t not be an ID. Also, as I read over the document, it is hard to follow what= the use cases are as it is very verbose. >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Apr 18, 2017 at 11:27 AM, Phil Hunt ; wrote: >>>>>>>>>>>=20 >>>>>>>>>>> > All, >>>>>>>>>>> > >>>>>>>>>>> > Dick asked me if I would enumerate the SCIM use cases. Here i= s the SCIM >>>>>>>>>>> > case. Happy to put these somewhere in a working group document= . >>>>>>>>>>>=20 >>>>>>>>>>>> On Wed, May 3, 2017 at 4:16 PM, Phil Hunt wrote: >>>>>>>>>>>> My understanding was you wanted informal cases not IDs. The SCI= M cases have been posted to the mailing list. I believe Marius is close on t= he RISC cases. >>>>>>>>>>>>=20 >>>>>>>>>>>> Phil >>>>>>>>>>>>=20 >>>>>>>>>>>> Oracle Corporation, Identity Cloud Services Architect & Standar= ds >>>>>>>>>>>> @independentid >>>>>>>>>>>> www.independentid.com >>>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>>=20 >>>>>>>>>>>>> On May 3, 2017, at 3:56 PM, Dick Hardt w= rote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Phil / Marius >>>>>>>>>>>>>=20 >>>>>>>>>>>>> At the Chicago meeting, the two of you agreed to work on a doc= ument containing use cases you considered to be relevant for secevent so tha= t the WG could decide which ones were in scope and which ones were out of sc= ope. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Checking in on the status of the use case document. Would you p= rovide an update when you have a chance? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> /Dick >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Id-event mailing list >>>>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DHWdy4Q9= fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g&s=3DJTwCxbXPzY_A62IiywTMIjRB-XsMY8UPafB= s4oPwOTc&e=3D=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> --=20 >>>>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I a= m working on! >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Id-event mailing list >>>>>>>>>>> Id-event@ietf.org >>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5= YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DbAI2H661a= 1QkItfplrd3RIM36dgAhF4WdbWxW8BOy4Q&s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUeth= VbuCS8&e=3D=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on! >>>>>>>>> _______________________________________________ >>>>>>>>> Id-event mailing list >>>>>>>>> Id-event@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0= 57SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DgwGItrqQynlr86zX= GtWnR-LWrcrcTS6Ly1w14yDo0vk&s=3Dt5e3IvZ_e-KRHUBVMfjtwKEs74yLZva4z-6OkkgmSjo&= e=3D=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> Subscribe to the HARDTWARE mail list to learn about projects I am working= on! >=20 --Apple-Mail-4976D896-9C79-46CF-BD84-579457054D1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Marius

Thanks!

I plan to publish the= SCIM cases as well soon. 

Phil=

On Jun 29, 2017, at 4:42 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

I just submitted the RIS= C use cases at:

It is very basic right now, I just= wanted to make sure that there is at least a basic version submitted before= the deadline.

I will expand the descriptions and a= dd diagrams.

Let me know if anyone else would like t= o be an author.

Marius


Marius

On Wed, May 31, 2017 at 6:24 PM, Dick Hardt <= span dir=3D"ltr"><dick.hardt@gmail.com> wrote:
Agreed. There is no requirement for these to be in the s= ame document.

On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.= hunt@oracle.com> wrote:
Marius,

Go ahead an s= ubmit as an individual draft. I will submit scim cases in a separate draft.&= nbsp;

Afaik there is no plan to have this he a single wg document.&= nbsp;

Phil

O= n May 31, 2017, at 9:22 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

=
Here is an initial use= case document, for now it has only the RISC use cases we discussed so far. W= hen Phil gets back I will coordinate with him to add SCIM use cases to this s= ame I-D. I will get this into a decent shape for the IETF meeting.

Marius

On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffe= r <yaronf.ietf@gmail.com> wrote:
=20 =20 =20

Whatever works for you - and that's the whole point of *individual* I-Ds.

Thanks,

    Yaron


On 04/05/17 18:25, Marius Scurtescu wrote:
Do we need one document for all use cases (all profiles) or one for each profiles?

I am happy to create the one document or the one for RISC (if one per profile).

Marius

On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

My strong preference would be an individual I-D that (as Justin says) will NOT be pushed to RFC. Why an I-D at all? Because this is what IETF folks are used to, and it is referenced from the WG agenda and minutes.

Thanks,

    Yaron


On 04/05/17 07:57, Justin Richer wrote:
In fact, I=E2=80=99m going to a= sk that we *not* push a use cases document toward RFC. Use case documents are wonderful tools for guiding development, but should be discarded as artifacts of that process once said process is completed (or even well on its way).

As such, RFC, wiki, blog post, or anything referenced from the list and easily findable works.

 =E2=80=94 Justin

On May 3, 2017, at 4:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

As the more experienced chair, I will defer to Yaron for guidance.

So far no one has expected it to be adopted as an RFC

On Wed, May 3, 2017 at 4:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Depends on what the WG wants.
=

Email cases,
Github posted document,
Individual IDs posted to the working group, or
an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE has RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft https://tools.ietf.org/h= tml/draft-ietf-oauth-use-cases-03).

Let us know what form and what format.

We can also use one for OpenID Backchannel Logout.  This is particularly important because it will be triggered by (or is related to) SCIM and by RISC events such as account resets, authentication factor changes etc.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independenti= d
phil.hunt@oracle.com

On May 3, 2017, at 4:31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Phil

per 

you offered to put them in a WG doc (see quate below). Would that not be an ID. Also, as I read over the document, it is hard to follow what the use cases are as it is very verbose.

On Tue, Apr 18, 2017 a=
t 11:27 AM, Phil Hunt <phil.hunt@oracle.com>; wrote:

> All,
>
> Dick asked me if I would enumerate the SCIM use cases.  Here is the SCI=
M
> case. Happy to put these somewhere in a working group document.
<= br>
On Wed, May 3, 2017 at 4:16 PM, Phil Hunt <phil.hunt@oracle.com= > wr= ote:
My understanding was you wanted informal cases not IDs. The SCIM cases have been posted to the mailing list. I believe Marius is close on the RISC cases.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independenti= d
phil.hunt@oracle.com

On May 3, 2017, at 3:56 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

P= hil / Marius

At the Chicago meeting, the two of you agreed to work on a document containing use cases you considered to be relevant for secevent so that the WG could decide which ones were in scope and which ones were out of scope.

Checking in on the status of the use case document. Would you provide an update when you have a chance?

/Dick

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v= 2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DHWdy4Q9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g&s=3DJTwCxbXPzY_A62IiywTMIjRB-XsMY8UPafBs4oPwOTc&e=3D

-- 
Subscribe to the HARD= TWARE mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-= 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0= FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DbAI2H661a1QkItfplrd3RIM36dgA= hF4WdbWxW8BOy4Q&s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS= 8&e=3D 




--
Subscribe to the HARDT= WARE mail list= to learn about projects I am working on!
______________= _________________________________
Id-event mailing list
I= d-event@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/id-event





<draft-scur= tescu-secevent-use-cases.txt>
<draft-scurtescu-secevent-use-cases.pdf>



--
Subscribe to the HARDTWARE mail list to learn about projects I am w= orking on!

= --Apple-Mail-4976D896-9C79-46CF-BD84-579457054D1D-- From nobody Thu Jun 29 17:21:24 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F25128C81 for ; Thu, 29 Jun 2017 17:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwC1BgmUbvzI for ; Thu, 29 Jun 2017 17:21:19 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788CA1200F3 for ; Thu, 29 Jun 2017 17:21:19 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id i2so87643141qta.3 for ; Thu, 29 Jun 2017 17:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QaVyCA8H2SGzzkaYNtIAZTU7AfiR1iYix7HjIqDchg0=; b=GUcz6S0Mu1ThlAIYjkEulABj0O7Ygqt3cgE3TCBWr7Ve0hFZtQDIfPSh4K9w6Su68v a0wR7UaJNM/7XpCB7gbhiZvG9jpoNpxTK9TBUOUcnNyGJcIQauuFQyS/9ESA3bKmJZFz RSDKwsPifoPXEjeQN+EkmGRKpeEVAu7J7uF8+GXDnyTo4LOmtqJZXpyWC4srvvBnqxye D1iK+Nq7QhpGo8y4vHm6m7jcwm5RlIw4nJmnqaLWBWzep7vN6Npqd3xz85tARWPJVNso wxs4L4vRF7ZyMZfNRUTA9w7wvdyQKOemL2IeGZ6PJHlsPBZcmmRT2t2cFgC6MK4phdae ZU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QaVyCA8H2SGzzkaYNtIAZTU7AfiR1iYix7HjIqDchg0=; b=PRyWbeJQMg03Q+STzCAJHwT7eDiyce2PsYANYpyLLAunZ08NoXKyOQjVeuHrPfYMWf s0nEt45X6rpoVDamKRNLj5UZYhNzbBFwqUM92pCp0FhectEm8eN4uc5I3ufEbJeQ3FzR FEXjFddGYEBh909CZCLCJ13rfrm83I+Dyg9KniCeQHM0CM+C7+ZvFyBsnTJmhVz5Bij5 i3sI30K9qPTET+1oXPIyTO9Q84JTQIPbmwd5qkLIqYK6NOIjrWahtmAACuncXJTgPohQ PXZkvZOtdKLL42rPpalIuMc40yzFW/9kjX7WizsKZMzRU0ujikz3EQIee4xCqdymQxdp vrjg== X-Gm-Message-State: AKS2vOwEXf3CRM123PqGzR2lCe0PNVzptfdv4q86JnKkFXQ85W6mJ3J3 P7pBRdE0E7T5wc739MsaBO2V9qIwyA== X-Received: by 10.200.53.243 with SMTP id l48mr24167822qtb.7.1498782078433; Thu, 29 Jun 2017 17:21:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.132 with HTTP; Thu, 29 Jun 2017 17:20:57 -0700 (PDT) In-Reply-To: References: <2104A459-8402-4498-9F7F-3EED264DB4E8@oracle.com> <2F79A80F-AE98-4372-B096-C26ED77F4C3B@mit.edu> <10de4c6f-c0a7-9d9f-c524-fa87048dd580@gmail.com> From: Dick Hardt Date: Thu, 29 Jun 2017 17:20:57 -0700 Message-ID: To: Mike Jones Cc: Marius Scurtescu , Yaron Sheffer , SecEvent , Justin Richer , "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary="001a114574f4617fe605532265c1" Archived-At: Subject: Re: [Id-event] Use case document X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:21:24 -0000 --001a114574f4617fe605532265c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wearing my secevent chair hat. We asked secevent participants to provide use cases. Marius was writing them for RISC. As I recall, Phil was going to write them for SCIM. On Thu, Jun 29, 2017 at 5:17 PM, Mike Jones wrote: > Wearing my OpenID member hat =E2=80=93 why isn=E2=80=99t this a RISC work= ing group > document, rather than an SECEVENT working group document? > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] * On Behalf Of *Mariu= s > Scurtescu > *Sent:* Thursday, June 29, 2017 4:42 PM > *To:* Dick Hardt > *Cc:* Yaron Sheffer ; SecEvent = ; > Justin Richer ; Phil Hunt (IDM) > *Subject:* Re: [Id-event] Use case document > > > > I just submitted the RISC use cases at: > > https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases-00 > > > > It is very basic right now, I just wanted to make sure that there is at > least a basic version submitted before the deadline. > > > > I will expand the descriptions and add diagrams. > > > > Let me know if anyone else would like to be an author. > > > > Marius > > > > > Marius > > > > On Wed, May 31, 2017 at 6:24 PM, Dick Hardt wrote: > > Agreed. There is no requirement for these to be in the same document. > > > > On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) > wrote: > > Marius, > > > > Go ahead an submit as an individual draft. I will submit scim cases in a > separate draft. > > > > Afaik there is no plan to have this he a single wg document. > > Phil > > > On May 31, 2017, at 9:22 PM, Marius Scurtescu > wrote: > > Here is an initial use case document, for now it has only the RISC use > cases we discussed so far. When Phil gets back I will coordinate with him > to add SCIM use cases to this same I-D. I will get this into a decent sha= pe > for the IETF meeting. > > > Marius > > > > On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffer > wrote: > > Whatever works for you - and that's the whole point of *individual* I-Ds. > > Thanks, > > Yaron > > > > On 04/05/17 18:25, Marius Scurtescu wrote: > > Do we need one document for all use cases (all profiles) or one for each > profiles? > > > > I am happy to create the one document or the one for RISC (if one per > profile). > > > Marius > > > > On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer > wrote: > > My strong preference would be an individual I-D that (as Justin says) wil= l > NOT be pushed to RFC. Why an I-D at all? Because this is what IETF folks > are used to, and it is referenced from the WG agenda and minutes. > > Thanks, > > Yaron > > > > On 04/05/17 07:57, Justin Richer wrote: > > In fact, I=E2=80=99m going to ask that we *not* push a use cases document= toward > RFC. Use case documents are wonderful tools for guiding development, but > should be discarded as artifacts of that process once said process is > completed (or even well on its way). > > > > As such, RFC, wiki, blog post, or anything referenced from the list and > easily findable works. > > > > =E2=80=94 Justin > > > > On May 3, 2017, at 4:45 PM, Dick Hardt wrote: > > > > As the more experienced chair, I will defer to Yaron for guidance. > > > > So far no one has expected it to be adopted as an RFC > > > > On Wed, May 3, 2017 at 4:39 PM, Phil Hunt wrote: > > Depends on what the WG wants. > > > > Email cases, > > Github posted document, > > Individual IDs posted to the working group, or > > an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE has > RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft > https://tools.ietf.org/html/draft-ietf-oauth-use-cases-03 > > ). > > > > Let us know what form and what format. > > > > We can also use one for OpenID Backchannel Logout. This is particularly > important because it will be triggered by (or is related to) SCIM and by > RISC events such as account resets, authentication factor changes etc. > > > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect & Standards > > @independentid > > www.independentid.com > > > phil.hunt@oracle.com > > > > On May 3, 2017, at 4:31 PM, Dick Hardt wrote: > > > > Hi Phil > > > > per > > > > https://mailarchive.ietf.org/arch/msg/id-event/FGuz9IsUMKqKeq2OjEBjCZ9cBc= I > > > > > you offered to put them in a WG doc (see quate below). Would that not be > an ID. Also, as I read over the document, it is hard to follow what the u= se > cases are as it is very verbose. > > > > On Tue, Apr 18, 2017 at 11:27 AM, Phil Hunt ; wrote: > > > > > All, > > > > > > Dick asked me if I would enumerate the SCIM use cases. Here is the SCI= M > > > case. Happy to put these somewhere in a working group document. > > > > On Wed, May 3, 2017 at 4:16 PM, Phil Hunt wrote: > > My understanding was you wanted informal cases not IDs. The SCIM cases > have been posted to the mailing list. I believe Marius is close on the RI= SC > cases. > > > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect & Standards > > @independentid > > www.independentid.com > > > phil.hunt@oracle.com > > > > On May 3, 2017, at 3:56 PM, Dick Hardt wrote: > > > > Phil / Marius > > > > At the Chicago meeting, the two of you agreed to work on a document > containing use cases you considered to be relevant for secevent so that t= he > WG could decide which ones were in scope and which ones were out of scope= . > > > > Checking in on the status of the use case document. Would you provide an > update when you have a chance? > > > > /Dick > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DHWdy4Q9fHAYB3f- > DZ2GWUJnaZDGcZQRaMexC2oHuR7g&s=3DJTwCxbXPzY_A62IiywTMIjRB- > XsMY8UPafBs4oPwOTc&e=3D > > > > > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > bAI2H661a1QkItfplrd3RIM36dgAhF4WdbWxW8BOy4Q&s=3D > fzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS8&e=3D > > > > > > > > -- > > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > > > > > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DgwGItrqQynlr86zXGtWnR- > LWrcrcTS6Ly1w14yDo0vk&s=3Dt5e3IvZ_e-KRHUBVMfjtwKEs74yLZva4z-6OkkgmSjo&e= =3D > > > > > > -- > > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a114574f4617fe605532265c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wearing my secevent chair hat.

We asked= secevent participants to provide use cases. Marius was writing them for RI= SC. As I recall, Phil was going to write them for SCIM.

On Thu, Jun 29, 2017 at 5= :17 PM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

Wearing my OpenID memb= er hat =E2=80=93 why isn=E2=80=99t this a RISC working group document, rath= er than an SECEVENT working group document?

<= span style=3D"color:#002060">=C2=A0

From: Id-event [mailto:id-event-bounces@ietf.org= ] On Behalf Of Marius Scurtescu
Sent: Thursday, June 29, 2017 4:42 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>; Justin Rich= er <jricher@mit.edu= >; Phil Hunt (IDM) <phil.hunt@oracle.com>
Subject: Re: [Id-event] Use case document

=C2=A0

I just submitted the RISC use cases at:

=C2=A0

It is very basic right now, I just wanted to make su= re that there is at least a basic version submitted before the deadline.=

=C2=A0

I will expand the descriptions and add diagrams.<= /u>

=C2=A0

Let me know if anyone else would like to be an autho= r.

=C2=A0

Marius

=C2=A0


Marius

=C2=A0

On Wed, May 31, 2017 at 6:24 PM, Dick Hardt <dick.hardt@gmail.com<= /a>> wrote:

Agreed. There is no requirement for these to be in t= he same document.

=C2=A0

On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) <= ;phil.hunt@oracle= .com> wrote:

Marius,

=C2=A0

Go ahead an submit as an individual draft. I will su= bmit scim cases in a separate draft.=C2=A0

=C2=A0

Afaik there is no plan to have this he a single wg d= ocument.=C2=A0

Phil


On May 31, 2017, at 9:22 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

Here is an initial use case document, for now it has= only the RISC use cases we discussed so far. When Phil gets back I will co= ordinate with him to add SCIM use cases to this same I-D. I will get this i= nto a decent shape for the IETF meeting.


Marius

=C2=A0

On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffer <<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com> wrote:

Whatever works for you - and that's the whole point of *individual* = I-Ds.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 04/05/17 18:25, Marius Scurtescu wrote:=

Do we need one document for all use cases (all profi= les) or one for each profiles?

=C2=A0

I am happy to create the one document or the one for= RISC (if one per profile).


Marius

=C2=A0

On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer <yaronf.ietf@gmail.= com> wrote:

My strong preference would be an individual I-D that (as Justin says) wi= ll NOT be pushed to RFC. Why an I-D at all? Because this is what IETF folks= are used to, and it is referenced from the WG agenda and minutes.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

On 04/05/17 07:57, Justin Richer wrote:

In fact, I=E2=80=99m going to ask that we *not* push= a use cases document toward RFC. Use case documents are wonderful tools fo= r guiding development, but should be discarded as artifacts of that process= once said process is completed (or even well on its way).

=C2=A0

As such, RFC, wiki, blog post, or anything reference= d from the list and easily findable works.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

On May 3, 2017, at 4:45 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

As the more experienced chair, I will defer to Yar= on for guidance.

=C2=A0

So far no one has expected it to be adopted as an = RFC

=C2=A0

On Wed, May 3, 2017 at 4:39 PM, Phil Hunt=C2=A0<phil.hunt@oracle.co= m>= =C2=A0wrote:

Depends on what the WG wants.=

=C2=A0

Email cases,

Github posted document,

Individual IDs posted to the working group, or<= /u>

an ID that gets adopted as a WG draft to end up as= RFC (e.g. JOSE has RFC7165, and SCIM itself had RFC7642, Oauth had a WG dr= aft=C2=A0<= /span>https://tools.ietf.org/html/draft-ietf-oauth-use-cases-03= ).

=C2=A0

Let us know what form and what format.

=C2=A0

We can also use one for OpenID Backchannel Logout.= =C2=A0 This is particularly important because it will be triggered by (or i= s related to) SCIM and by RISC events such as account resets, authentication factor changes etc.

=C2=A0

Phil

=C2=A0

Oracle Corporation, Identity Cloud Services Archit= ect & Standards

@independentid

phil.hunt@oracle.com

=C2=A0

On May 3, 2017, at 4:31 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Hi Phil

=C2=A0

per=C2=A0

=C2=A0

=C2=A0

you offered to put them in a WG doc (see quate bel= ow). Would that not be an ID. Also, as I read over the document, it is hard= to follow what the use cases are as it is very verbose.

=C2=A0

=
On Tue, Apr 18, 2017 at =
11:27 AM, Phil Hunt <phil.hunt@oracle.com>=
; wrote:
=C2=A0
> All,
>=C2=A0
> Dick asked me if I would enumerate the SCIM use cases.=C2=
=A0 Here is the SCIM
> case. Happy to put these somewhere in a working group docum=
ent.

=C2=A0

On Wed, May 3, 2017 at 4:16 PM, Phil Hunt=C2=A0<phil.hunt@oracle.co= m>= =C2=A0wrote:

My understanding was you wanted informal cases not= IDs. The SCIM cases have been posted to the mailing list. I believe Marius= is close on the RISC cases.

=C2=A0

Phil

=C2=A0

Oracle Corporation, Identity Cloud Services Archit= ect & Standards

@independentid

phil.hunt@oracle.com

=C2=A0

On May 3, 2017, at 3:56 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Phil / Marius

=C2=A0

At the Chicago meeting, the two of you agreed to w= ork on a document containing use cases you considered to be relevant for se= cevent so that the WG could decide which ones were in scope and which ones were out of scope.

=C2=A0

Checking in on the status of the use case document= . Would you provide an update when you have a chance?<= /p>

=C2=A0

/Dick

=C2=A0

_____________________________________________= __
Id-event mailing list
Id-event@ietf.org
https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listin= fo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX= 5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4= C_lLIGk&m=3DHWdy4Q9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g&<= wbr>s=3DJTwCxbXPzY_A62IiywTMIjRB-XsMY8UPafBs4oPwOTc&e=3D=C2=A0=

=C2=A0



=C2=A0

--=C2=A0

Subscribe to the=C2=A0= HARDTWARE=C2=A0mail list to learn about projects I am working on!

_____________________________________________= __
Id-event mailing list
Id-event@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP= 1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0Fk= ITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DbAI2H661a1QkItfplrd3RIM36dgAh= F4WdbWxW8BOy4Q&s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUeth= VbuCS8&e=3D=C2=A0

=C2=A0



=C2=A0

--=C2=A0

Subscribe to the=C2=A0= HARDTWARE=C2=A0mail list to learn about projects I am working on!

_____________________________________________= __
Id-event mailing list
Id-event@= ietf.org
https://= www.ietf.org/mailman/listinfo/id-event

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

<draft-scurtescu-secevent-use-cases.txt><= u>

<draft-scurtescu-secevent-use-cases.pdf><= u>



=C2=A0

--

Subscribe to the HARDTWARE mail list to learn about projects I am working on!<= /u>

=C2=A0




--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
--001a114574f4617fe605532265c1-- From nobody Thu Jun 29 17:21:55 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CFD129466 for ; Thu, 29 Jun 2017 17:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuiowDEoWPuF for ; Thu, 29 Jun 2017 17:21:51 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC484126BF7 for ; Thu, 29 Jun 2017 17:21:50 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v143so5574496qkb.0 for ; Thu, 29 Jun 2017 17:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nro0hLEGwF+5UgPQURZr+dblEnZ8pzpWxr4W1mKH7ns=; b=ppjf0VFKn/uB97ECkUkT+/euJ5/dHwJl9RG+jvIcEJ5bZR2Z5F48voXJ5bqfwpaM9D R5G957LMDKqTFaFMp+InlJv6LyYWhlabFxxyiywQ5Rrs3k1N/2MwCHym+LPxfjHtQKeS N8+yqIKJcz3FJPxdJG/+4zQg1RhNzZyiCgjPFKeABgKb3CgDMq4j/4JFo7x4sKIfkQoZ 1+pc/l3CSigI1SXsBsfm2qUhQgL+jzXrSN/f+b20T2TDgRQdHJrrMzsuXwpOg3F9HliQ C6HDu7hZlCjCFeMGlaTbHapD6efIJNDrwaXb9pUCFJFMSLgxdTEIpZF0KjAqzUf0RTEr zWlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nro0hLEGwF+5UgPQURZr+dblEnZ8pzpWxr4W1mKH7ns=; b=CssuMDE5p9vwjCjMj7sJx8mkFlR/GvZVWsXql98KNeqEYUJlFzCxAuN7FJHCyFkuXf 2XBU0FwGaOjMTdB+0NCRQcQ0lb8Qhkv4k4qbyYpPt6pQRGgVXtn3ktEzGW0K2f2BKB/H XjLHA7U5a/O54a2VZ+JHtsenpk1nN6+zs30qpxIxQEU6ER55Nd5oaqqX9nHgvGtcimz/ 7P2rTt0c02jxC1UbN5aOqIMAi2B9IxrevLf5Diyusx18KL1YE2UbUc5GaGb7jYM++qaL GqBygz9uZ55anjhR+50Vrp06aett6aDJJ2VDtq6S1hROQUMe7uk8dQ+QvV7DkPZrlEHX pVdw== X-Gm-Message-State: AKS2vOxhiTHbyWRxaF1mPsTqrM161Bm7EZEtwVwj0Tdl4ZozPCX0g1gP rt2fE2SI2s6cWhAy3DUDgclRRnU2BQ== X-Received: by 10.55.155.141 with SMTP id d135mr21323474qke.11.1498782109865; Thu, 29 Jun 2017 17:21:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.132 with HTTP; Thu, 29 Jun 2017 17:21:28 -0700 (PDT) In-Reply-To: <01231318-9B1C-4814-954F-F52A4EC802D1@oracle.com> References: <2104A459-8402-4498-9F7F-3EED264DB4E8@oracle.com> <2F79A80F-AE98-4372-B096-C26ED77F4C3B@mit.edu> <10de4c6f-c0a7-9d9f-c524-fa87048dd580@gmail.com> <01231318-9B1C-4814-954F-F52A4EC802D1@oracle.com> From: Dick Hardt Date: Thu, 29 Jun 2017 17:21:28 -0700 Message-ID: To: "Phil Hunt (IDM)" Cc: Marius Scurtescu , Yaron Sheffer , SecEvent , Justin Richer Content-Type: multipart/alternative; boundary="94eb2c07684a411fa3055322673b" Archived-At: Subject: Re: [Id-event] Use case document X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:21:55 -0000 --94eb2c07684a411fa3055322673b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Phil! On Thu, Jun 29, 2017 at 5:20 PM, Phil Hunt (IDM) wrote: > Marius > > Thanks! > > I plan to publish the SCIM cases as well soon. > > Phil > > On Jun 29, 2017, at 4:42 PM, Marius Scurtescu > wrote: > > I just submitted the RISC use cases at: > https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases-00 > > > It is very basic right now, I just wanted to make sure that there is at > least a basic version submitted before the deadline. > > I will expand the descriptions and add diagrams. > > Let me know if anyone else would like to be an author. > > Marius > > > Marius > > On Wed, May 31, 2017 at 6:24 PM, Dick Hardt wrote: > >> Agreed. There is no requirement for these to be in the same document. >> >> On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) >> wrote: >> >>> Marius, >>> >>> Go ahead an submit as an individual draft. I will submit scim cases in = a >>> separate draft. >>> >>> Afaik there is no plan to have this he a single wg document. >>> >>> Phil >>> >>> On May 31, 2017, at 9:22 PM, Marius Scurtescu >>> wrote: >>> >>> Here is an initial use case document, for now it has only the RISC use >>> cases we discussed so far. When Phil gets back I will coordinate with h= im >>> to add SCIM use cases to this same I-D. I will get this into a decent s= hape >>> for the IETF meeting. >>> >>> Marius >>> >>> On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffer >>> wrote: >>> >>>> Whatever works for you - and that's the whole point of *individual* >>>> I-Ds. >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> On 04/05/17 18:25, Marius Scurtescu wrote: >>>> >>>> Do we need one document for all use cases (all profiles) or one for >>>> each profiles? >>>> >>>> I am happy to create the one document or the one for RISC (if one per >>>> profile). >>>> >>>> Marius >>>> >>>> On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer >>>> wrote: >>>> >>>>> My strong preference would be an individual I-D that (as Justin says) >>>>> will NOT be pushed to RFC. Why an I-D at all? Because this is what IE= TF >>>>> folks are used to, and it is referenced from the WG agenda and minute= s. >>>>> >>>>> Thanks, >>>>> >>>>> Yaron >>>>> >>>>> On 04/05/17 07:57, Justin Richer wrote: >>>>> >>>>> In fact, I=E2=80=99m going to ask that we *not* push a use cases docu= ment >>>>> toward RFC. Use case documents are wonderful tools for guiding develo= pment, >>>>> but should be discarded as artifacts of that process once said proces= s is >>>>> completed (or even well on its way). >>>>> >>>>> As such, RFC, wiki, blog post, or anything referenced from the list >>>>> and easily findable works. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On May 3, 2017, at 4:45 PM, Dick Hardt wrote: >>>>> >>>>> As the more experienced chair, I will defer to Yaron for guidance. >>>>> >>>>> So far no one has expected it to be adopted as an RFC >>>>> >>>>> On Wed, May 3, 2017 at 4:39 PM, Phil Hunt wr >>>>> ote: >>>>> >>>>>> Depends on what the WG wants. >>>>>> >>>>>> Email cases, >>>>>> Github posted document, >>>>>> Individual IDs posted to the working group, or >>>>>> an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE ha= s >>>>>> RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft >>>>>> https://tools.ietf.org/html/draft-ietf-oauth-use-cases-03 >>>>>> >>>>>> ). >>>>>> >>>>>> Let us know what form and what format. >>>>>> >>>>>> We can also use one for OpenID Backchannel Logout. This is >>>>>> particularly important because it will be triggered by (or is relate= d to) >>>>>> SCIM and by RISC events such as account resets, authentication facto= r >>>>>> changes etc. >>>>>> >>>>>> Phil >>>>>> >>>>>> Oracle Corporation, Identity Cloud Services Architect & Standards >>>>>> @independentid >>>>>> www.independentid.com >>>>>> >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> On May 3, 2017, at 4:31 PM, Dick Hardt wrote: >>>>>> >>>>>> Hi Phil >>>>>> >>>>>> per >>>>>> >>>>>> https://mailarchive.ietf.org/arch/msg/id-event/FGuz9IsUMKqKe >>>>>> q2OjEBjCZ9cBcI >>>>>> >>>>>> >>>>>> you offered to put them in a WG doc (see quate below). Would that no= t >>>>>> be an ID. Also, as I read over the document, it is hard to follow wh= at the >>>>>> use cases are as it is very verbose. >>>>>> >>>>>> On Tue, Apr 18, 2017 at 11:27 AM, Phil Hunt <= phil.hunt@oracle.com>>; wrote: >>>>>> >>>>>> > All, >>>>>> > >>>>>> > Dick asked me if I would enumerate the SCIM use cases. Here is th= e SCIM >>>>>> > case. Happy to put these somewhere in a working group document. >>>>>> >>>>>> >>>>>> On Wed, May 3, 2017 at 4:16 PM, Phil Hunt wr >>>>>> ote: >>>>>> >>>>>>> My understanding was you wanted informal cases not IDs. The SCIM >>>>>>> cases have been posted to the mailing list. I believe Marius is clo= se on >>>>>>> the RISC cases. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> Oracle Corporation, Identity Cloud Services Architect & Standards >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> On May 3, 2017, at 3:56 PM, Dick Hardt wrote= : >>>>>>> >>>>>>> Phil / Marius >>>>>>> >>>>>>> At the Chicago meeting, the two of you agreed to work on a document >>>>>>> containing use cases you considered to be relevant for secevent so = that the >>>>>>> WG could decide which ones were in scope and which ones were out of= scope. >>>>>>> >>>>>>> Checking in on the status of the use case document. Would you >>>>>>> provide an update when you have a chance? >>>>>>> >>>>>>> /Dick >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Id-event mailing list >>>>>>> Id-event@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzj >>>>>>> WwlNKe4C_lLIGk&m=3DHWdy4Q9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g >>>>>>> &s=3DJTwCxbXPzY_A62IiywTMIjRB-XsMY8UPafBs4oPwOTc&e=3D >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Subscribe to the HARDTWARE >>>>>> >>>>>> mail list to learn about projects I am working on! >>>>>> _______________________________________________ >>>>>> Id-event mailing list >>>>>> Id-event@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzj >>>>>> WwlNKe4C_lLIGk&m=3DbAI2H661a1QkItfplrd3RIM36dgAhF4WdbWxW8BOy4Q >>>>>> &s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS8&e=3D >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Subscribe to the HARDTWARE >>>>> >>>>> mail list to learn about projects I am working on! >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzj >>> WwlNKe4C_lLIGk&m=3DgwGItrqQynlr86zXGtWnR-LWrcrcTS6Ly1w14yDo0vk >>> &s=3Dt5e3IvZ_e-KRHUBVMfjtwKEs74yLZva4z-6OkkgmSjo&e=3D >>> >>> >> >> >> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> > > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c07684a411fa3055322673b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Phil!

On Thu, Jun 29, 2017 at 5:20 PM, Phil Hunt (IDM) <phi= l.hunt@oracle.com> wrote:
<= div dir=3D"auto">
Marius

= Thanks!

I plan to publish the= SCIM cases as well soon.=C2=A0

Phil

On Jun 29, 2017, at 4:42 PM,= Marius Scurtescu <mscurtescu@google.com> wrote:

I just submitted the RISC use cases at:
https://tools.ietf.org/html/draft-scurtescu-secevent-ri= sc-use-cases-00

It is very basic righ= t now, I just wanted to make sure that there is at least a basic version su= bmitted before the deadline.

I will expand the des= criptions and add diagrams.

Let me know if anyone = else would like to be an author.

Marius
=

Marius

On Wed, May 31, 2017 at 6:24 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:
Agreed. There is no requirement for these to be in = the same document.

On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) <phil.hun= t@oracle.com> wrote:
Marius= ,

Go ahead an submit= as an individual draft. I will submit scim cases in a separate draft.=C2= =A0

Afaik there is n= o plan to have this he a single wg document.=C2=A0

Phil

On May 3= 1, 2017, at 9:22 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

Here is an initial use cas= e document, for now it has only the RISC use cases we discussed so far. Whe= n Phil gets back I will coordinate with him to add SCIM use cases to this s= ame I-D. I will get this into a decent shape for the IETF meeting.

Marius

On Thu, May 4, 2017 at 11:28 AM, Yaron Sheff= er <yaronf.ietf@gmail.com> wrote:
=20 =20 =20

Whatever works for you - and that's the whole point of *individual* I-Ds.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron


On 04/05/17 18:25, Marius Scur= tescu wrote:
Do we need one document for all use cases (all profiles) or one for each profiles?

I am happy to create the one document or the one for RISC (if one per profile).

Marius

On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

My strong preference would be an individual I-D that (as Justin says) will NOT be pushed to RFC. Why an I-D at all? Because this is what IETF folks are used to, and it is referenced from the WG agenda and minutes.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron


On 04/05/17 07:57, Justin Richer wrote:
In fact, I=E2=80=99m going to = ask that we *not* push a use cases document toward RFC. Use case documents are wonderful tools for guiding development, but should be discarded as artifacts of that process once said process is completed (or even well on its way).

As such, RFC, wiki, blog post, or anything referenced from the list and easily findable works.

=C2=A0=E2=80=94 Justin

On May 3, 2017, at 4:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

As the more experienced chair, I will defer to Yaron for guidance.

So far no one has expected it to be adopted as an RFC

On Wed, May 3, 2017 at 4:39 PM, Phil Hunt=C2=A0<phil= .hunt@oracle.com>=C2=A0wrote:
Depends on what the WG wants.

Email cases,
Github posted document,
Individual IDs posted to the working group, or
an ID that gets adopted as a WG draft to end up as RFC (e.g. JOSE has RFC7165, and SCIM itself had RFC7642, Oauth had a WG draft=C2=A0<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf= .org_html_draft-2Dietf-2Doauth-2Duse-2Dcases-2D03&d=3DDwMFaQ&c=3DRo= P1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPE= ivzjWwlNKe4C_lLIGk&m=3DgwGItrqQynlr86zXGtWnR-LWrcrcTS6Ly1w14yDo0vk&= s=3D_t4GRDPaCMns1jW640uMNo_o5BHH8kJCCQXUTLi9Qak&e=3D" target=3D"_blank"= >https://tools.ietf.org/html/draft-ietf-oauth-use-cases-03).<= /div>

Let us know what form and what format.

We can also use one for OpenID Backchannel Logout.=C2=A0 This is particularly important because it will be triggered by (or is related to) SCIM and by RISC events such as account resets, authentication factor changes etc.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independent= id
phil.hunt@oracle.com

On May 3, 2017, at 4:31 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

Hi Phil

per=C2=A0


you offered to put them in a WG doc (see quate below). Would that not be an ID. Also, as I read over the document, it is hard to follow what the use cases are as it is very verbose.

On Tue, Apr 18, 2017 at 11:27 AM, Phil Hunt <phil.hunt@ora=
cle.com>; wrote:

> All,
>
> Dick asked me if I would enumerate the SCIM use cases.  Here is the SC=
IM
> case. Happy to put these somewhere in a working group document.
=
On Wed, May 3, 2017 at 4:16 PM, Phil Hunt=C2=A0<phil.hunt@oracle.com>=C2=A0wrote:
My understanding was you wanted informal cases not IDs. The SCIM cases have been posted to the mailing list. I believe Marius is close on the RISC cases.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independent= id
phil.hunt@oracle.com

On May 3, 2017, at 3:56 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

= Phil / Marius

At the Chicago meeting, the two of you agreed to work on a document containing use cases you considered to be relevant for secevent so that the WG could decide which ones were in scope and which ones were out of scope.

Checking in on the status of the use case document. Would you provide an update when you have a chance?

/Dick

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Deven= t&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&a= mp;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DHWdy4Q= 9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g&s=3DJTwCxbXPzY_A62IiywT= MIjRB-XsMY8UPafBs4oPwOTc&e=3D=C2=A0




--=C2=A0
Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDw= ICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D= JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DbAI2H661a1QkI= tfplrd3RIM36dgAhF4WdbWxW8BOy4Q&s=3DfzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS8&e=3D=C2=A0




--=C2=A0
Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to learn about projects I am working on!
__________= _____________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event





<draft-scu= rtescu-secevent-use-cases.txt>
<draft-scurtescu-secevent-use-cases.pdf>



--
Subscribe to the HARDTWARE mail list to learn about projects I am= working on!




--
Subscribe to the HARD= TWARE mail list to learn about projects I am working on!
--94eb2c07684a411fa3055322673b-- From nobody Thu Jun 29 18:28:25 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E241294C8 for ; Thu, 29 Jun 2017 18:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu3w_ihsPNvZ for ; Thu, 29 Jun 2017 18:28:23 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C0C126B7F for ; Thu, 29 Jun 2017 18:28:23 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5U1SJM7024894 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 01:28:20 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5U1SJNn009805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 01:28:19 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5U1SJYe025378; Fri, 30 Jun 2017 01:28:19 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 18:28:19 -0700 From: "Phil Hunt (IDM)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 29 Jun 2017 18:28:17 -0700 Message-Id: <74C2BB30-33EF-4D22-9437-51CD4F8228B5@oracle.com> Cc: ID Events Mailing List To: Dick Hardt , Yaron Sheffer X-Mailer: iPhone Mail (14F89) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [Id-event] Time slots for secevents X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 01:28:24 -0000 Chairs I would like to request time slots to discuss the following documents. As I c= annot make it, I am listing the proposed speakers: * SET Token - Mike to cover issues since Chicago * SET Delivery - Marius, new individual draft proposal (to be posted shortly= ) covering push and poll delivery * Secevent usecases SCIM - Tony to present the scim use cases draft (to be p= osted shortly) * Secevent usecases RISC - Marius to present the RISC use cases draft Thanks to all the co-authors: Marius, Mike, Tony, Annabelle and Morteza thes= e past few weeks for helping to get these documents finished in time for the= group to review for Prague. I recognize everyone has had a lot of limited t= ime this quarter and appreciate the time. As a result, I think the drafts a= nd our proposal has really improved.=20 Thanks and sorry I can't be there! Phil= From nobody Thu Jun 29 20:36:52 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C94126DCA for ; Thu, 29 Jun 2017 20:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzHzSNPQNjYD for ; Thu, 29 Jun 2017 20:36:48 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14A51200CF for ; Thu, 29 Jun 2017 20:36:48 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id h134so17759240iof.2 for ; Thu, 29 Jun 2017 20:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IgOPAeLEaosMNeVd3S5NC2XiVbBP3CdVYZZ2uOryppg=; b=RriM56DqgpWmHfmhGTeBar9cgqwJ/oWo10lOCu2pqxKWROyF1Z4j5VxmSCeAfqEKZY 1kCCfRqAbvfdLd3qy5QZprpa3wtklAhZbAqkJw1FIPGAXIWKiTd9uNK/Mutcybf05q1p GEKJ/8V1FAU4sePjYfXYqv3uIaWEXM0BJj5iya3KAXWbUeeKY2nsbE/Ay1qXZWPwQ9DV xSeoz+1ZlCoZssSNx9F4vcxWHq6yx+Lhn5JT/oYbbTh32iDQOBPXgj83Lz8jPWp+K/1s /+Mk+z0t8RdbfyeJ2a9k1v4xznIu4aW4+6ES5+5vNbbi2hkwn7I31BgO52xDNRvGSMhk CTuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IgOPAeLEaosMNeVd3S5NC2XiVbBP3CdVYZZ2uOryppg=; b=uSeTrPFxq55OqeFsbFUa8pcbMngETyBtdc/HFLyRxCp7nbidWYE2XwwwTxagEvarnT tFCeEg/60oSLMoatJFKqYkRt5WWFo1BEEq7KvzdUvemYt0Bu8UIeJzdyOWQD8JHmC988 5py5jSS8qrgOE/MXRZw1L07bfMwlkKRG7nk0QcL+QfDVegLq2ij163J1iQFN5LdOoqlo yUBdLktgmhuhEILWPMO85zH5vcuEWjAUbyJIhb0ZUdorSvjK1ShEVNJk9yxWIfyiOR6t BzVN+7pU3/5wXj8wE2QwYvrEKI4URy25ksjeAXrI6OpwLkpYD0XHPn2ogR2lh6Mtya2L TPvg== X-Gm-Message-State: AKS2vOwwSEkopD6jbP5SyhaP4O1u6whNBoQ+mPEnA92N/gbtFGJ/Llih +mRZPh/ZPygVbTwnLFEXwYxL14Q7NQ== X-Received: by 10.107.137.161 with SMTP id t33mr19961182ioi.181.1498793807954; Thu, 29 Jun 2017 20:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.145.5 with HTTP; Thu, 29 Jun 2017 20:36:27 -0700 (PDT) In-Reply-To: <74C2BB30-33EF-4D22-9437-51CD4F8228B5@oracle.com> References: <74C2BB30-33EF-4D22-9437-51CD4F8228B5@oracle.com> From: Dick Hardt Date: Thu, 29 Jun 2017 20:36:27 -0700 Message-ID: To: "Phil Hunt (IDM)" Cc: Dick Hardt , Yaron Sheffer , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a113ecad683e12305532520de" Archived-At: Subject: Re: [Id-event] Time slots for secevents X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 03:36:50 -0000 --001a113ecad683e12305532520de Content-Type: text/plain; charset="UTF-8" Hi Phil Sorry you won't make it there. I think we had already anticipated these items in our agenda. Thanks for double checking. /Dick On Thu, Jun 29, 2017 at 6:28 PM, Phil Hunt (IDM) wrote: > Chairs > > I would like to request time slots to discuss the following documents. As > I cannot make it, I am listing the proposed speakers: > > * SET Token - Mike to cover issues since Chicago > * SET Delivery - Marius, new individual draft proposal (to be posted > shortly) covering push and poll delivery > * Secevent usecases SCIM - Tony to present the scim use cases draft (to be > posted shortly) > * Secevent usecases RISC - Marius to present the RISC use cases draft > > Thanks to all the co-authors: Marius, Mike, Tony, Annabelle and Morteza > these past few weeks for helping to get these documents finished in time > for the group to review for Prague. I recognize everyone has had a lot of > limited time this quarter and appreciate the time. As a result, I think > the drafts and our proposal has really improved. > > Thanks and sorry I can't be there! > > Phil > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a113ecad683e12305532520de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil

Sorry you won't make it the= re. I think we had already anticipated these items in our agenda. Thanks fo= r double checking.

/Dick

On Thu, Jun 29, 2017 at 6:28 PM= , Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Chairs

I would like to request time slots to discuss the following documents. As I= cannot make it, I am listing the proposed speakers:

* SET Token - Mike to cover issues since Chicago
* SET Delivery - Marius, new individual draft proposal (to be posted shortl= y) covering push and poll delivery
* Secevent usecases SCIM - Tony to present the scim use cases draft (to be = posted shortly)
* Secevent usecases RISC - Marius to present the RISC use cases draft

Thanks to all the co-authors: Marius, Mike, Tony, Annabelle and Morteza the= se past few weeks for helping to get these documents finished in time for t= he group to review for Prague. I recognize everyone has had a lot of limite= d time this quarter and appreciate the time.=C2=A0 As a result, I think the= drafts and our proposal has really improved.

Thanks and sorry I can't be there!

Phil
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



--
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
--001a113ecad683e12305532520de-- From nobody Thu Jun 29 22:42:06 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18A7127698 for ; Thu, 29 Jun 2017 22:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncxXmiPuXz-Q for ; Thu, 29 Jun 2017 22:42:04 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7E51200CF for ; Thu, 29 Jun 2017 22:42:04 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5U5g1Sb013650 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 05:42:02 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5U5g12R005239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 05:42:01 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5U5g0pd020563; Fri, 30 Jun 2017 05:42:01 GMT Received: from [192.168.1.25] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 22:42:00 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_6CD21774-B9C4-4536-9E89-9B148D417FE2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 22:41:55 -0700 Message-Id: To: ID Events Mailing List X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Id-event] Bouncing emails and membership suspensions X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 05:42:05 -0000 --Apple-Mail=_6CD21774-B9C4-4536-9E89-9B148D417FE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just so everyone knows, as the id-events mailing list admin, I have been = receiving a number of bounced emails from several domains such as = gmail.com, google.com, and paypal which after a number of repeats can = result in suspensions from the list, The cause seems to be messages = posted from microsoft.com and a possible DMARC policy problem. I have escalated the issue to the ietf action list and hopefully there = is a solution. Note: if you are aware of colleagues not getting this email (because = the bouncing has caused them to be suspended), please let them know. Thanks, Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_6CD21774-B9C4-4536-9E89-9B148D417FE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just so everyone knows, as the id-events mailing list admin, = I have been receiving a number of bounced emails from several domains = such as gmail.com, google.com, and paypal which = after a number of repeats can result in suspensions from the list, The = cause seems to be messages posted from microsoft.com and a possible DMARC policy problem.

I have escalated the = issue to the ietf action list and hopefully there is a = solution.

Note:  if you are aware of colleagues not getting this = email (because the bouncing has caused them to be suspended), please let = them know.

Thanks,

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_6CD21774-B9C4-4536-9E89-9B148D417FE2-- From nobody Thu Jun 29 22:52:02 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8A6127698 for ; Thu, 29 Jun 2017 22:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_gl2K8cL5bQ for ; Thu, 29 Jun 2017 22:51:59 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0124.outbound.protection.outlook.com [104.47.36.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA19F12009C for ; Thu, 29 Jun 2017 22:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZkIVQM2vMBCoCye0CwdZPx23YeUHDoUTvaeMqPURU34=; b=eD10ZF515CWyfczYTB2cPv7oRHBhnBMaRwz/RfLJSCC4cA6SJwJbDFGZ7eoI0yV3ojc/1LQmt05VKAoSdNHxozct4+m17Zr4CLOsK74UO3PpGL4R4eTt1U4IMFjEtCONizxoe2Ufk/0dPX2J4KQPk7vO6oQ6doVWXB0oxXJ0XlI= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0471.namprd21.prod.outlook.com (10.172.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.1; Fri, 30 Jun 2017 05:51:57 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 05:51:56 +0000 From: Mike Jones To: Phil Hunt , ID Events Mailing List , Yaron Sheffer Thread-Topic: Bouncing emails and membership suspensions Thread-Index: AQHS8WOdD5EoAuwXqUeyYBDdzHVBTKI85y/p Date: Fri, 30 Jun 2017 05:51:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0471; 7:uCp4ToAqt29IGHbuxWlUqPc5PEhiTJoyPkDx7OVnRMNBxAfpNgei2qjdj7k9RJZ7c6aZoe3hJAvHLFIXYcFlCVL8r4GtZFg0hfue1DjutzLeZYndiJRTrLtb5rT21N4zEC26qx0KGqxQzwlQpwOnZU/QfpeSrilUHuyX6cxR0/1gdU3V8ntItux2i0inTOqrqNmJ5/CvrNFUdOiPdRHKZ5SLTy1tepzfYp0SIZRtK+iPCdekDYfyI11FVq1Vo82H6S6SzOEuH6EGXDBpr9o0+5++TOGiDOhdc6AoiewRkEEzZSZamM3HntFtqt95kuKHQu6tYt3c6vJTzVNVHe5Xu1lxu4ByhEjVkbqwXtO4XRjeSrh+iprqkaZiYo37XanGgq2X65LGBt4cPvrOhDdyg7DVtOQFm+q/CQ22rTE92Xz9+EDbr/w8TxkWlW+l4wEqvs8Tbq5Fjr2ClIk68BGQfK8ORvDcOqW/RyuC8RxY708kkFp5y/OSk7OKuQsjRCgVV9znEhtg8j7c74k8wRZ1M09Uh4nTW0us/AR9ue1OcnA1xMkw3+yVrCnhihtJVjl/HcmwNhTMZamjY5K9b48H+ehNbqqyn1RgJF3iiemwxVQV3apQJtwOVrzm2QCbGdhHxzMtcr0LzYd4IosTE9yNx/F6XnuKc98KA+jLwv8mVydiUmgMC9a3Lvex7lwvOEZrU53N1FCgQoz/kZH1eK08jfiVW6fBQyinUEguUOGfo0ECLKAK9lAPGtW3QIkeYnoAG93hADK1Tyc+Nbmt0en4efrg0ANq3+AaSLFw+L5Yq1+5J836LQPT61QS3nznbqdq x-ms-office365-filtering-correlation-id: 045c7ede-8057-44a8-327d-08d4bf7c1e1b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0471; x-ms-traffictypediagnostic: CY4PR21MB0471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(26388249023172)(236129657087228)(211936372134217)(146099531331640)(158140799945019); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(2017060910020)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0471; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0471; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(69234005)(377454003)(3905003)(5005710100001)(53936002)(72206003)(8936002)(81166006)(7696004)(478600001)(33656002)(2950100002)(229853002)(8990500004)(2900100001)(77096006)(6506006)(6436002)(53546010)(5660300001)(14454004)(8676002)(10090500001)(86362001)(7736002)(74316002)(606006)(189998001)(50986999)(76176999)(54356999)(10290500003)(2906002)(3280700002)(86612001)(6246003)(25786009)(6116002)(102836003)(99286003)(53386004)(55016002)(9686003)(54896002)(6306002)(236005)(38730400002)(3846002)(3660700001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0471; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05041514883A98D51F5B7934F5D30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 05:51:56.6156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0471 Archived-At: Subject: Re: [Id-event] Bouncing emails and membership suspensions X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 05:52:02 -0000 --_000_CY4PR21MB05041514883A98D51F5B7934F5D30CY4PR21MB0504namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, Tony's membership has been suspended and he can=92t rejoin. =96 Mike From: Phil Hunt Sent: Thursday, June 29, 2017 10:42 PM To: ID Events Mailing List Subject: Bouncing emails and membership suspensions Just so everyone knows, as the id-events mailing list admin, I have been re= ceiving a number of bounced emails from several domains such as gmail.com, google.com, and paypal which after a n= umber of repeats can result in suspensions from the list, The cause seems t= o be messages posted from microsoft.com and a possibl= e DMARC policy problem. I have escalated the issue to the ietf action list and hopefully there is a= solution. Note: if you are aware of colleagues not getting this email (because the b= ouncing has caused them to be suspended), please let them know. Thanks, Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com phil.hunt@oracle.com --_000_CY4PR21MB05041514883A98D51F5B7934F5D30CY4PR21MB0504namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

FYI, Tony's membership has been suspended and he can= =92t rejoin.

 

=96 Mike

 

From: Phil Hunt
Sent: Thursday, June 29, 2017 10:42 PM
To: ID Events Mailing List<= br> Subject: Bouncing emails and membership suspensions

 

Just so everyone knows, as the id-events mailing list admin, I have be= en receiving a number of bounced emails from several domains such as gmail.com, google.com, and paypal which after a number of repeats can result in su= spensions from the list, The cause seems to be messages posted from microsoft.com and a possibl= e DMARC policy problem.

I have escalated the issue to the ietf action list and hope= fully there is a solution.

Note:  if you are aware of colleagues not getting this= email (because the bouncing has caused them to be suspended), please let t= hem know.

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect &= Standards
@independentid
www.ind= ependentid.com
phil.hunt@oracle.com

--_000_CY4PR21MB05041514883A98D51F5B7934F5D30CY4PR21MB0504namp_-- From nobody Thu Jun 29 23:02:17 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247EA1201F2 for ; Thu, 29 Jun 2017 23:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id talvwUwJnreZ for ; Thu, 29 Jun 2017 23:02:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBF71200ED for ; Thu, 29 Jun 2017 23:02:13 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5U62CuR014097 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 06:02:12 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v5U62BcM008997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 06:02:12 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5U62Bjm021151; Fri, 30 Jun 2017 06:02:11 GMT Received: from [192.168.1.25] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jun 2017 23:02:10 -0700 From: Phil Hunt Message-Id: <727D12D5-98A3-4F4D-B60E-430C45FF0EAB@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B6B5102B-D0B7-4D22-B11F-7C8F4FBD37C7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 29 Jun 2017 23:02:08 -0700 In-Reply-To: Cc: ID Events Mailing List , Yaron Sheffer , Tony Nadalin To: Mike Jones References: X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Id-event] Bouncing emails and membership suspensions X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 06:02:16 -0000 --Apple-Mail=_B6B5102B-D0B7-4D22-B11F-7C8F4FBD37C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, Thanks. I have re-added Tony. =20 All: Please let me know of any colleagues who are having issues. I have reset all the suspensions I have found as well. =20 Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 29, 2017, at 10:51 PM, Mike Jones = wrote: >=20 > FYI, Tony's membership has been suspended and he can=E2=80=99t rejoin. > =20 > =E2=80=93 Mike > =20 > From: Phil Hunt > Sent: Thursday, June 29, 2017 10:42 PM > To: ID Events Mailing List > Subject: Bouncing emails and membership suspensions > =20 > Just so everyone knows, as the id-events mailing list admin, I have = been receiving a number of bounced emails from several domains such as = gmail.com = , google.com = , and paypal which = after a number of repeats can result in suspensions from the list, The = cause seems to be messages posted from microsoft.com = and a possible = DMARC policy problem. >=20 > I have escalated the issue to the ietf action list and hopefully there = is a solution. >=20 > Note: if you are aware of colleagues not getting this email (because = the bouncing has caused them to be suspended), please let them know. >=20 > Thanks, >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com = phil.hunt@o= racle.com --Apple-Mail=_B6B5102B-D0B7-4D22-B11F-7C8F4FBD37C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike,

Thanks.  I have re-added Tony.  

All:  Please let me = know of any colleagues who are having issues.

I have reset all the suspensions I have = found as well.  

=
Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 29, 2017, at 10:51 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

FYI, Tony's membership has been suspended and he can=E2=80=99t = rejoin.
 
=E2=80=93 = Mike
 
From: Phil Hunt
Sent: Thursday, June 29, 2017 = 10:42 PM
To: ID Events Mailing List
Subject: Bouncing emails and = membership suspensions
 
Just so everyone knows, as the id-events mailing list admin, = I have been receiving a number of bounced emails from several domains = such as gmail.com, google.com, and paypal which after a number of repeats = can result in suspensions from the list, The cause seems to be messages = posted from microsoft.com and a possible DMARC policy = problem.

I have = escalated the issue to the ietf action list and hopefully there is a = solution.

Note:  if you are aware of colleagues not getting this = email (because the bouncing has caused them to be suspended), please let = them know.

Thanks,

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_B6B5102B-D0B7-4D22-B11F-7C8F4FBD37C7-- From nobody Thu Jun 29 23:18:19 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61010127A91 for ; Thu, 29 Jun 2017 23:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWNsoiZsFK45 for ; Thu, 29 Jun 2017 23:18:15 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901411273B1 for ; Thu, 29 Jun 2017 23:18:15 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v202so56271081itb.0 for ; Thu, 29 Jun 2017 23:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=pC6hQhUEmnwAbVUuoZSVJgxRKIe3RFfLgwkxfzJejFw=; b=GE1PmX373UH9zeXez3w4c5TuIg4i7OlDSQcfgJwHCDoY2qyDoaEvogpRBUyKMcNwUo KpRD/F5SzpIFI1/wIMTRrCe/b//koAGAqpd6RPguOKNyKAcvFM0CK171GYXQnnLE/SS/ U4anKyyTfSd2hWKYX7qa/ZfDvekk6Bkzz341fOThjuervW44LjAWj6W1BNxyOLAyo+KD uykh0SQJDqJRSq8i2djxL0Myr/xKV5YfycIbVYJu9c2ZWwA/AgSGFjo4/DZgezxVSRbv MbO32QD5XZ27IaBHKmZ4kaJnXD9a2gJd9XDM03hztsRDw62+vBOP69CYrZJNcQo1WSyQ ZCkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pC6hQhUEmnwAbVUuoZSVJgxRKIe3RFfLgwkxfzJejFw=; b=rrM/OglqclS4oVktkJm/Nvb85sN9a5hzVPY136od4bF03HiEGFsUEM2L0a2C9ob8O6 aHYZfLwYPh8v0dFPnX87fRjcc9EZzKEtP3ASzCzdbDRETxhQSaf3vB0c2BbGC1i9AKfD cccQbl3wTn+qEznJdVSqwYOAMJXoSUY8g5LQO+rgpJsEmOM088eMSARsd0C4HctWRWqt xU5rZxDmaIvkciV1/mEIeGiHNhqKDgeGayCz9ftzXaVQoI57DZSteYt8kgD9mMGmO+zm ZkhNfKzxX/6J1KxcmFytNgYAzLicR/KUx9MaIa8pw8k9MOOWaxc69p2K7sLnfQihNfHL mMSg== X-Gm-Message-State: AKS2vOwHzevjN8E8Hh9CRBeCkJNAmP7DaeXN13h+ZGfjPr3ZQQV1OhYn YS/qk3RXr3u2fZzxQ6YSuC8xMAwW4+ulcITLRw== X-Received: by 10.36.108.131 with SMTP id w125mr1186341itb.91.1498803494353; Thu, 29 Jun 2017 23:18:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 29 Jun 2017 23:17:53 -0700 (PDT) From: Marius Scurtescu Date: Thu, 29 Jun 2017 23:17:53 -0700 Message-ID: To: ID Events Mailing List Cc: "Richard Backman, Annabelle" , Phillip Hunt Content-Type: multipart/alternative; boundary="001a1147e2a4df36010553276111" Archived-At: Subject: [Id-event] Management API for SET Event Streams X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 06:18:17 -0000 --001a1147e2a4df36010553276111 Content-Type: text/plain; charset="UTF-8" Earlier today I submitted the "Management API for SET Event Streams" I-D: https://tools.ietf.org/html/draft-scurtescu-secevent-simple-control-plane-00 The purpose is to compare a plain REST approach (provided by this I-D) with a SCIM based approach in order to help select the best solution. Marius --001a1147e2a4df36010553276111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Earlier today I submitted the "Management API for SET= Event Streams" I-D:

= The purpose is to compare a plain REST approach (provided by this I-D) with= a SCIM based approach in order to help select the best solution.

Marius
--001a1147e2a4df36010553276111-- From nobody Thu Jun 29 23:26:37 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CCC128AB0 for ; Thu, 29 Jun 2017 23:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJhNEIg8vIKk for ; Thu, 29 Jun 2017 23:26:32 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B345F127444 for ; Thu, 29 Jun 2017 23:26:32 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r36so19079254ioi.1 for ; Thu, 29 Jun 2017 23:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gk050t0WA9HO0TzlFGp9OrEdrW8n0SaldGCc5eS6gR4=; b=HQ3qt9Rkc+g3qe9+9Qjpu8vzVpixSY4jmAb2Q60u+0Kznaub+PWBzk4VcdK9rxrLFR SNdpGAsWM7IUNDLVS2pqZfl0GV2YjssTwkkc3dn+/TC4/K4oSRBax/2/xJnEX2fNgQYG zR69g4pV0E0FdCSlYbadhydEZcMfbaOWyRasvRNvvWgQXpLSXkVBgIZEkudAjGuJuNSl Cb2Ge+Fdjq1QcdEo9SVQA/PWLno/59c17XCbuVMnfBWj2vq2nPm8m5nKnIixSYSw1hc+ OsOudYqCPlEQBlYUnrEJv2pmfCGt9ILWx8tpMg2HINzpcYsGT5okGqzxnAB9UVswkIhm 0Dng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gk050t0WA9HO0TzlFGp9OrEdrW8n0SaldGCc5eS6gR4=; b=e141ODS69Xw33eIV11q9E/9A77oi3SlkDMdt7beCuMk0l9407Hco/2H4oHLDkd4Gw1 lbCsZ4YOtMfS6eP5Y880jI+3ghTTrfRj4V8RFVeErQhTqj+0wZSZ1yXu9s9U7wf+gKsj I07D5u1W4N1rd1JByCDU646G/gdFKqmrWFyljhB2HvaOU1b+gccES4PPsmjffPSes3Og O8VKuLRnSkdKAShNlL7oZgB1/He98sPD7KAVDfETTg3EF9E0UR/MqATbYZs9IkpfiNTB hhngiNNiueCWSvqSTVXeZXZRfLhpew7/EZAB5fzSdOpfDSdOGprUENv+TYtwxECEwN7Y sE0w== X-Gm-Message-State: AKS2vOyUsgtEFa5A3dWckXfMdnaNguapeJyFsVBOzq3xeO8Fc8KGUAXn 2uEjoBXeFaIpQAYF3IwEUYJpE4kfzy5O X-Received: by 10.107.18.19 with SMTP id a19mr20416846ioj.93.1498803991742; Thu, 29 Jun 2017 23:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.36 with HTTP; Thu, 29 Jun 2017 23:26:11 -0700 (PDT) In-Reply-To: References: <74C2BB30-33EF-4D22-9437-51CD4F8228B5@oracle.com> From: Marius Scurtescu Date: Thu, 29 Jun 2017 23:26:11 -0700 Message-ID: To: Dick Hardt Cc: "Phil Hunt (IDM)" , Yaron Sheffer , Dick Hardt , ID Events Mailing List , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="001a113ee86e8486a10553277f06" Archived-At: Subject: Re: [Id-event] Time slots for secevents X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 06:26:35 -0000 --001a113ee86e8486a10553277f06 Content-Type: text/plain; charset="UTF-8" Can we also get a time slot for "Management API for SET Event Streams"? This is the plain REST control plane. Either Annabelle or myself could present. Since Annabelle contributed a lot to this I-D and since I am presenting two other documents, I think it would be best if she could present. Thanks, Marius Marius On Thu, Jun 29, 2017 at 8:36 PM, Dick Hardt wrote: > Hi Phil > > Sorry you won't make it there. I think we had already anticipated these > items in our agenda. Thanks for double checking. > > /Dick > > On Thu, Jun 29, 2017 at 6:28 PM, Phil Hunt (IDM) > wrote: > >> Chairs >> >> I would like to request time slots to discuss the following documents. As >> I cannot make it, I am listing the proposed speakers: >> >> * SET Token - Mike to cover issues since Chicago >> * SET Delivery - Marius, new individual draft proposal (to be posted >> shortly) covering push and poll delivery >> * Secevent usecases SCIM - Tony to present the scim use cases draft (to >> be posted shortly) >> * Secevent usecases RISC - Marius to present the RISC use cases draft >> >> Thanks to all the co-authors: Marius, Mike, Tony, Annabelle and Morteza >> these past few weeks for helping to get these documents finished in time >> for the group to review for Prague. I recognize everyone has had a lot of >> limited time this quarter and appreciate the time. As a result, I think >> the drafts and our proposal has really improved. >> >> Thanks and sorry I can't be there! >> >> Phil >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a113ee86e8486a10553277f06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can we also get a time slot for "Management API for S= ET Event Streams"? This is the plain REST control plane.

Either Annabelle or myself could present. Since Annabelle contributed= a lot to this I-D and since I am presenting two other documents, I think i= t would be best if she could present.

Thanks,
Marius


Marius

On Thu, Jun 29, 2017 at 8:36 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:
Hi Phil

Sorry you won't make= it there. I think we had already anticipated these items in our agenda. Th= anks for double checking.

/Dick

O= n Thu, Jun 29, 2017 at 6:28 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Chairs

I would like to request time slots to discuss the following documents. As I= cannot make it, I am listing the proposed speakers:

* SET Token - Mike to cover issues since Chicago
* SET Delivery - Marius, new individual draft proposal (to be posted shortl= y) covering push and poll delivery
* Secevent usecases SCIM - Tony to present the scim use cases draft (to be = posted shortly)
* Secevent usecases RISC - Marius to present the RISC use cases draft

Thanks to all the co-authors: Marius, Mike, Tony, Annabelle and Morteza the= se past few weeks for helping to get these documents finished in time for t= he group to review for Prague. I recognize everyone has had a lot of limite= d time this quarter and appreciate the time.=C2=A0 As a result, I think the= drafts and our proposal has really improved.

Thanks and sorry I can't be there!

Phil
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



--
Subscribe to the HARDTWARE mail list to learn ab= out projects I am working on!

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--001a113ee86e8486a10553277f06-- From nobody Fri Jun 30 09:33:49 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95C1126557 for ; Fri, 30 Jun 2017 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yHpiP8RxMpg for ; Fri, 30 Jun 2017 09:33:44 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65A3130A94 for ; Fri, 30 Jun 2017 09:33:43 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i2so103182910qta.3 for ; Fri, 30 Jun 2017 09:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vTgrB4GbUvtDZaTL1sE4m09fuhQ+Iy9KTuLv4smegFc=; b=rY8yMi/7+xs1gKWEbgnEGlDr1ZzhitldP/dgfIi0SD14nJGw9rbkBY2C3gkxmk/Axz hnqj2zc9oMBjsB/pSQDPZiVf6V9v4YIlFU+xYZ8A5+6aQxUebNM09gO9r1ZarMpW/XsF HLvwqpQWSWohjhHybSLqpBVuimtw3RuufjRo77E1ap2L+MpTYaFSNPA8Oz4ZjOoiuEx5 pURhJLBvnnixsB8fNUDsQALDNUoTwSZIHd8bXIdVBqyWsYWLp+eBPyUIFE9kv6+gdWlq yeaLMzv2E66PXoSsBidyTqH6ez61+TMMJBKInRFTBuZAeCbnPWlmTglSCrEn1oi0yOvq FyRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vTgrB4GbUvtDZaTL1sE4m09fuhQ+Iy9KTuLv4smegFc=; b=uLxF4bYbe0NpHtbLZDZZiq//uNQBAiLqFWYVRatlEdYLAnuFvhcZJhb3O9Dqa29K5w wxzkeY7SEfOk0pVxT8thRX6j3TFJnSEz/KNKNS1uEitONV6/5Oa8CrOzu4UZm6V9Q4rQ h5a8vKCdwaxgKmrYqGIDYd118hTBm10Gg8Wp9uMxHgf7woOJM7FC5YDFs9t2LromDF2F x2djh12kfmEHuArJFyfESOjY8o1uNi3EK+G06Zj8nQnIzOmBnng4M+niOHuAGpF8hPTH 5D09X1vmH4LQkOs5U9vbmHgk8/dKtEBvuLvaDj5aolF10KEl22ersp5NjOBuuqgLPNum d73A== X-Gm-Message-State: AKS2vOzXXfQKGqtrgQA6az/QFw/L12NDtrWeXinBdT8/yFcFXD+OC5/W FQb1kBSC2RPWpGTmpKN4Od0tpdwmoCMY X-Received: by 10.237.32.177 with SMTP id 46mr26854915qtb.56.1498840422732; Fri, 30 Jun 2017 09:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Fri, 30 Jun 2017 09:33:22 -0700 (PDT) In-Reply-To: <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> From: William Denniss Date: Fri, 30 Jun 2017 09:33:22 -0700 Message-ID: To: "Phil Hunt (IDM)" Cc: Nat Sakimura , Dick Hardt , Mike Jones , "id-event@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0ca4eaf9548505532ffa93" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 16:33:48 -0000 --94eb2c0ca4eaf9548505532ffa93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to typ. So "typ": "set" or "typ": "event"? On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) wrote: > +1 to typ claim. > > Phil > > On Jun 29, 2017, at 5:01 PM, Nat Sakimura wrote: > > Sorry for a tardy reply, but +1 for the both changes. 'exp' claim > requirement is a good practical step with a backward compatibility. > Having said that, I believe inferring message types from the > existence/absence of a claim is not a good security practice. I would lik= e > to see an explicit typing through "typ" claim added as well. > > Nat > > On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) > wrote: > >> Ok. >> >> I spoke with Mike and he will post his changes to SET in a new revision >> over the weekend. >> >> Phil >> >> On Jun 29, 2017, at 1:51 PM, Dick Hardt wrote: >> >> I understand it is new and that there is contention. >> >> We clearly want consensus for us to be done with the draft. I think >> having it in the next draft anchors the discussion so we can discuss and >> arrive at consensus or an alternative. >> >> So yes, is like a new draft posted so we can discuss. >> >> On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote: >> >>> Dick, >>> >>> The section is a brand new section. It seems to me that has not been an= y >>> (or limited) discussion to warrant putting it in the document. It >>> certainly came to me as a surprise. >>> >>> I think the issue of trust model needs to be discussed. It may not >>> belong here at all. >>> >>> Please advise. Do you want it posted in spite of consensus? >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect & Standards >>> @independentid >>> www.independentid.com >>> >>> phil.hunt@oracle.com >>> >>> On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: >>> >>> Hi Phil >>> >>> wrt asking for more discussion, I appreciate you making the suggestion >>> on behalf of the chairs. It does seem there is a reasonable amount of >>> discussion going on now would you not agree? >>> >>> I'd like to get the doc updated in time for Prague so that we have a >>> clear reference point for discussion there and then. >>> >>> Unclear why you would post a change when it was Mike that did this work= . >>> Am I missing something? >>> >>> Mike: would you update the doc with what you think is rough consensus >>> when you have time so that we can have a crisp discussion in Prague? >>> >>> >>> >>> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) >>> wrote: >>> >>>> I agree on the exp part. >>>> >>>> Regarding the second part. I would like to see more discussion. >>>> >>>> For example, in the the use cases, there may be compatibility issues i= f >>>> different set profiles cannot be sent over the same stream. >>>> >>>> Such profiles should avoid things like requiring signing and encryptio= n >>>> without consideration regarding how they are transferred. Also key >>>> management might be better tied up in how the streams are manages beca= use >>>> the network relationship may define the requirements rather than the d= ata. >>>> >>>> My initial reaction is, the profiles should stick to the data and vali= d >>>> interpretation. >>>> >>>> If the group agrees I will merge the exp and post over the weekend. >>>> >>>> I can merge the second part if there is a strong agreement to do so. >>>> >>>> Thanks! >>>> >>>> Phil >>>> >>>> On Jun 28, 2017, at 5:24 PM, William Denniss >>>> wrote: >>>> >>>> Thank you Mike for working on this. I'm very happy with the change >>>> regarding the "exp" claim, and believe it is the best resolution to th= e "ID >>>> Token" confusion concern. >>>> >>>> By making the "exp" claim that is already >>>> >>>> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID >>>> Tokens and SET uniqueness guarantee that is desired, allowing these tw= o >>>> types of JWTs to be used with a common issuer. This also allows "sub" = to be >>>> used for its intended purpose (as defined by RFC7519) without modifica= tion, >>>> which other working groups that wish to profile SET have expressed an >>>> interest to do >>>> >>>> The benefit the community will gain from the SET standard overall is a >>>> standard way to express events that won't conflict with ID Token (no "= iss" >>>> partitioning required). With Mike's changes we achieve that, and in a = way >>>> that retains the original simplicity, extensibility and generalizabili= ty >>>> goals of SET by not redefining any of JWT's standard claims. >>>> >>>> >>>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> >>>>> >>>>> I wanted to give you a heads-up about two SET spec updates in the >>>>> current editor=E2=80=99s draft before they are published. >>>>> >>>>> >>>>> >>>>> The first solves the potential ID Token / SET confusion problem by >>>>> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D cla= im when ID Tokens >>>>> could also be generated by the same issuer. Because =E2=80=9Cexp=E2= =80=9D is a required ID >>>>> Token claim, SETs would therefore be rejected by existing ID Token >>>>> validation code. Note that this solution is already recommended in t= he >>>>> specification. The editor=E2=80=99s draft update makes this solution= mandatory. >>>>> This provides a simple and durable solution to the problem we agreed = to >>>>> solve at IETF 98 in Chicago and that has been the subject of much >>>>> discussion since. >>>>> >>>>> >>>>> >>>>> The second adds the following new section: >>>>> >>>>> >>>>> >>>>> Requirements for SET Profiles >>>>> >>>>> >>>>> >>>>> Profile Specifications for SETs define the syntax and semantics of >>>>> SETs conforming to that SET profile and rules for validating those SE= Ts. >>>>> The syntax defined by profiling specifications includes what claims a= nd >>>>> event payload values are used by SETs utilizing the profile. >>>>> >>>>> >>>>> >>>>> Defining the semantics of the SET contents for SETs utilizing the >>>>> profile is equally important. Possibly most important is defining the >>>>> procedures used to validate the SET issuer and to obtain the keys >>>>> controlled by the issuer that were used for cryptographic operations = used >>>>> in the JWT representing the SET. For instance, some profiles may defi= ne an >>>>> algorithm for retrieving the SET issuer's keys that uses the iss >>>>> claim value as its input. >>>>> >>>>> >>>>> >>>>> Profile Specifications MUST clearly specify the steps that a recipien= t >>>>> of a SET utilizing that profile MUST perform to validate that the SET= is >>>>> both syntactically and semantically valid. >>>>> >>>>> >>>>> >>>>> It=E2=80=99s included to inform profile writers about what they must = do to be >>>>> able to use SETs securely. While much of the discussion as of late h= as >>>>> been about syntax, semantics is equally important, and must be consid= ered >>>>> by profile writers and deployers. >>>>> >>>>> >>>>> >>>>> I believe that the new section contains only statements that are >>>>> already factually accurate requirements but that were previously unst= ated. >>>>> The editor=E2=80=99s draft makes these requirements explicit. Feedba= ck on how to >>>>> make these requirements even more clear, is of course, welcomed. >>>>> >>>>> >>>>> >>>>> Best >>>>> wishes, >>>>> >>>>> -- >>>>> Mike >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz >>>> jWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH >>>> 0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=3D >>>> >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>>> >>>> >>>> >>> >>> >>> -- >>> Subscribe to the HARDTWARE >>> >>> mail list to learn about projects I am working on! >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz >>> jWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZtYUVk6T7HkwYGfXx- >>> 02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D >>> >>> >>> -- >> Subscribe to the HARDTWARE >> >> mail list to learn about projects I am working on! >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > --94eb2c0ca4eaf9548505532ffa93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to typ.

So "typ": "se= t" or "typ": "event"?

On Thu, Jun 29, 2017 at 5:17 PM, Phil Hu= nt (IDM) <phil.hunt@oracle.com> wrote:
+1 to typ claim.=C2=A0

Phil

On Jun 29, = 2017, at 5:01 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Sorry for a tardy reply, but=C2=A0+1 fo= r the both changes. 'exp' claim requirement is a good practical ste= p with a backward compatibility.=C2=A0
Having said that, I believe infe= rring message types from the existence/absence of a claim is not a good sec= urity practice. I would like to see an explicit typing through "typ&qu= ot; claim added as well.=C2=A0

Nat

=
On Fri, Jun 30, 2017 at 7:04 AM= Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Ok.=C2=A0

I spoke with Mike and he will post his changes to SET in = a new revision over the weekend.=C2=A0

Phil

On Jun 29, 2017, at 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I underst= and it is new and that there is contention.=C2=A0
We clearly want consensus for us to be done with = the draft. I think having it in the next draft anchors the discussion so we= can discuss and arrive at consensus or an alternative.=C2=A0

So yes, is like a new draft posted so= we can discuss.=C2=A0

On Thu, Jun= 29, 2017 at 12:58 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Dick,

The section is a brand new section. It seems to me that ha= s not been any (or limited) discussion to warrant putting it in the documen= t.=C2=A0 It certainly came to me as a surprise.

I = think the issue of trust model needs to be discussed.=C2=A0 It may not belo= ng here at all.

Please advise.=C2=A0 Do you want i= t posted in spite of consensus?

Phil

Oracle Corporation, Identity Cloud Services Architec= t & Standards
@independentid
phil.hunt@oracle.com=

On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

=
Hi Phil

wrt asking for more dis= cussion, I appreciate you making the suggestion on behalf of the chairs. It= does seem there is a reasonable amount of discussion going on now would yo= u not agree?

I'd like to get the doc updated i= n time for Prague so that we have a clear reference point for discussion th= ere and then.

Unclear why you would post a ch= ange when it was Mike that did this work. Am I missing something?

Mike: would you update the doc with what you think is rough= consensus when you have time so that we can have a crisp discussion in Pra= gue?



On Wed, Jun 28, 2017 at 5:38 PM, Phil Hu= nt (IDM) <phil.hunt@oracle.com> wrote:
I agree on the exp part.=C2=A0

Regarding the second part.= I would like to see more discussion.=C2=A0

For example, in the the use cases, there= may be compatibility issues if different set profiles cannot be sent over = the same stream.=C2=A0

Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred.=C2=A0 = Also key management might be better tied up in how the streams are manages = because the network relationship may define the requirements rather than th= e data.=C2=A0

My initial reaction is, the profiles should stick to the data and vali= d interpretation.=C2=A0

If the group agrees I will merge the exp and= post over the weekend.=C2=A0

I can merge the second part if there is a strong agree= ment to do so.=C2=A0

Thanks!

Phil

On Jun= 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you Mike for working on this. = I'm very happy with the change regarding the "exp" claim, and= believe it is the best resolution to the "ID Token" confusion co= ncern.

By making the "exp" claim that is= already NOT RECOMMENDED in the current draft a MUST NOT= , we can provide the ID Tokens and SET uniqueness guarantee that is desired= , allowing these two types of JWTs to be used with a common issuer. This al= so allows "sub" to be used for its intended purpose (as defined b= y RFC7519) without modification, which other working groups that wish to pr= ofile SET have expressed an interest to do

The ben= efit the community will gain from the SET standard overall is a standard wa= y to express events that won't conflict with ID Token (no "iss&quo= t; partitioning required). With Mike's changes we achieve that, and in = a way that retains the original simplicity, extensibility and generalizabil= ity goals of SET by not redefining any of JWT's standard claims.
<= div>

On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <Michael.Jones@microsoft.com<= /a>> wrote:

Hi folks,

=C2=A0

I wanted to give you a = heads-up about two SET spec updates in the current editor=E2=80=99s draft b= efore they are published.

= =C2=A0

The first solves the potential ID T= oken / SET confusion problem by requiring that SETs not include a top-level= =E2=80=9Cexp=E2=80=9D claim when ID Tokens could also be generated by the = same issuer.=C2=A0 Because =E2=80=9Cexp=E2=80=9D is a required ID Token cla= im, SETs would therefore be rejected by existing ID Token validation code.=C2=A0 Note tha= t this solution is already recommended in the specification.=C2=A0 The edit= or=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provide= s a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discu= ssion since.

=C2=A0

The second adds the following new section:<= u>

=C2=A0

<= a>Requirements for SET Profiles=

<= u>=C2=A0

P= rofile Specifications for SETs define the syntax and semantics of SETs conf= orming to that SET profile and rules for validating those SETs. The syntax = defined by profiling specifications includes what claims and event payload values are used by S= ETs utilizing the profile.

<= u>=C2=A0

D= efining the semantics of the SET contents for SETs utilizing the profile is= equally important. Possibly most important is defining the procedures used= to validate the SET issuer and to obtain the keys controlled by the issuer that were used for = cryptographic operations used in the JWT representing the SET. For instance= , some profiles may define an algorithm for retrieving the SET issuer's= keys that uses the iss claim value as its input.

<= u>=C2=A0

P= rofile Specifications MUST clearly specify the steps that a recipient of a = SET utilizing that profile MUST perform to validate that the SET is both sy= ntactically and semantically valid.

=C2=A0

It=E2=80=99s included to inform profile writers= about what they must do to be able to use SETs securely.=C2=A0 While much = of the discussion as of late has been about syntax, semantics is equally im= portant, and must be considered by profile writers and deployers.

=C2=A0

I believe that the new section contains only statem= ents that are already factually accurate requirements but that were previou= sly unstated.=C2=A0 The editor=E2=80=99s draft makes these requirements exp= licit.=C2=A0 Feedback on how to make these requirements even more clear, is of course, welcomed.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best w= ishes,

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

=C2=A0



_____= __________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
Subscribe to the HARDTWARE= mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing li= st
Id-event@ietf.= org
--
_____________________________________________= __
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


--94eb2c0ca4eaf9548505532ffa93-- From nobody Fri Jun 30 09:56:44 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5D4128961 for ; Fri, 30 Jun 2017 09:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBuIrnlnHBhb for ; Fri, 30 Jun 2017 09:56:37 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0138.outbound.protection.outlook.com [104.47.41.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6AC126C25 for ; Fri, 30 Jun 2017 09:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KaCuCwpnrheAVRXHm8nGqbzcXP+zDDMXmVSrgXIssGk=; b=GNWkFEElaKA2H6VzMeDNB24mJrLClWvrByyzRckVQoYSL4gTElaDmV753KC94QgDHsry/Tsae0fu/gybsXSca+eNv06sBioI9cvYxG5Q1b4pzDyh6CdTEAtgAa3DIKQXY/GnrAef/LW62JEMTcjwE+AHxVPkhbCrcYq/f+476FQ= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0135.namprd21.prod.outlook.com (10.173.189.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.3; Fri, 30 Jun 2017 16:56:35 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 16:56:35 +0000 From: Mike Jones To: William Denniss , "Phil Hunt (IDM)" CC: Nat Sakimura , Dick Hardt , "id-event@ietf.org" Thread-Topic: [Id-event] Heads-up about SET spec updates Thread-Index: AdLwa3VhxmOh1ap9Sxqj4ofmRP4gvAAApZIAAACBMYAAJ1aBgAABJWgAAAHadAAAApHigAAEEu8AAACVdYAAIhDoAAAAmlLg Date: Fri, 30 Jun 2017 16:56:34 +0000 Message-ID: References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-30T09:56:31.7523068-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0135; 7:Q+01CFtpDZk5SMzAqeFwStwcoST22fFgtbj+mnPqdNHFu0nKzK5+7E2RYzDL6x0ztK4B2n+l2/wJlg5NLd19oPYwx9HXSiX6wRvRqmapznqRMddlvThUwm3NZE/10IiVCITAfp8ShE6CDqUMJs+XfpdCPk5S/Z2VLEBbDSvXuNQaqg9Adl5EScsFG9yYuZ5lj3bNA60bsUq1fkXo0h6Vaf8wGSyrtWWGMis0sNCRkX5fgYmXsathQuS02FCU2pB5Jo/wselCMXjDjY39iflWW/fUI0lHsWxyVjCpOEPUwrF7hHBKw6m9eXPGk7tStfnsxm6p6wtR995ZJqasvgtz4R18ujLHM8FiVu0HhsjSAAqJI0Xy/8lf3LZOmy55fLli7JqLdell7BMcDbf1Me4qHB+x2drjUhD5Iq00rkeFcj7lwiXNLE5baFWYhEqg0mbQN9ZiHYmkqBUUcUldaPeu/fMfkPr6ms2ywHGS974A8tp1DuzN1m8bdNifmlB4dxtlDDbC9PpaR78g+El4kEqrkgtb3vLqh1Ozo1HxTmkKjTIaM8V1oqR3/lS2SKURsAoDQ6ozQt2qOudBVvfRX1z380ULEjCOu+/cvCM+La9yC40AsSkeBneVsH8p5pHl37jzeknMwRXwVS5HZ/GT5dGBxIUj4hgDsnzj1/rSH1ikCYXHL2mO1QGrVkVn00BfwKHpOcgSn8LSD6kHLecCxNPS3GhUk9wspKqXw0k6ov3pU19dDw6ysgboZCQ7+hwTtH+8z52Lo6cXPlgMzydCGIV5uuHuE75UDgA6dOpDwGUW4Uv4dIQAjazTCg40ti8twu1L x-ms-office365-filtering-correlation-id: b752e427-f5a6-4382-c7bb-08d4bfd8f765 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0135; x-ms-traffictypediagnostic: CY4PR21MB0135: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(10436049006162)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(211936372134217)(100405760836317)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910020)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0135; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0135; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39860400002)(39850400002)(39840400002)(39450400003)(377454003)(78124002)(76104003)(24454002)(6506006)(66066001)(74316002)(229853002)(81166006)(93886004)(7736002)(189998001)(14454004)(6246003)(53546010)(10290500003)(50986999)(966005)(77096006)(25786009)(72206003)(38730400002)(19609705001)(606006)(478600001)(54356999)(39060400002)(7110500001)(76176999)(4326008)(3660700001)(102836003)(6436002)(33656002)(2906002)(790700001)(5005710100001)(2420400007)(3846002)(8990500004)(6116002)(3280700002)(9686003)(6306002)(54906002)(8676002)(54896002)(53936002)(2950100002)(55016002)(5660300001)(7696004)(86362001)(8936002)(86612001)(575784001)(2900100001)(10090500001)(15650500001)(68736007)(99286003)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0135; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504A02DFC0137D090C50AEAF5D30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 16:56:34.8574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0135 Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 16:56:42 -0000 --_000_CY4PR21MB0504A02DFC0137D090C50AEAF5D30CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaGFkIGFscmVhZHkgYmVlbiBkaXNjdXNzaW9ucywgYm90aCBpbiBDaGljYWdvLCBhbmQg aW4gdGhlIEpXVCBCQ1AgY29udGV4dCwgdGhhdCBpZiB3ZSB3ZXJlIGdvaW5nIHRvIHVzZSBhIHR5 cGUgaWRlbnRpZmllciwgd2Ugd291bGQgdXNlIHRoZSBleGlzdGluZyDigJx0eXDigJ0gaGVhZGVy IHBhcmFtZXRlciBhbmQgbm90IGNyZWF0ZSBhIG5ldyBjbGFpbS4gIFRoaXMgaXMgYSBNSU1FIHR5 cGUsIHdpdGggdGhlIGFiaWxpdHkgdG8gb21pdCDigJxhcHBsaWNhdGlvbi/igJ0gZm9yIHNwYWNl IHJlYXNvbnMsIGlmIGRlc2lyZWQuDQoNClNpbmNlIHRoZXJlIGFwcGVhcnMgdG8gYmUgYnJvYWQg aW50ZXJlc3QgaW4gaGF2aW5nIHRoZSBhYmlsaXR5IHRvIHVzZSBleHBsaWNpdCB0eXBpbmcgb2Yg dGhlIFNFVCwgSSB3aWxsIHBsYW4gdG8gZGVmaW5lIHRoZSDigJxhcHBsaWNhdGlvbi9zZWNldmVu dCtqd3TigJ0gTUlNRSB0eXBlIGluIHRoZSBTRVQgZHJhZnQgYmVmb3JlIHB1Ymxpc2hpbmcuICBT RVRzIGNvdWxkIHRoZW4gaW5jbHVkZSB0aGUg4oCcdHlw4oCdOuKAnHNlY2V2ZW50K2p3dOKAnSBo ZWFkZXIgcGFyYW1ldGVyIHZhbHVlIHRvIHByb3ZpZGUgZXhwbGljaXQgdHlwaW5nLiAgVW5sZXNz IEkgaGVhciBvYmplY3Rpb25zIHNvb24sIEkgd2lsbCBwcm9jZWVkIG9uIHRoaXMgYmFzaXMuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5j b21dDQpTZW50OiBGcmlkYXksIEp1bmUgMzAsIDIwMTcgOTozMyBBTQ0KVG86IFBoaWwgSHVudCAo SURNKSA8cGhpbC5odW50QG9yYWNsZS5jb20+DQpDYzogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBn bWFpbC5jb20+OyBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT47IE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IGlkLWV2ZW50QGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0lkLWV2ZW50XSBIZWFkcy11cCBhYm91dCBTRVQgc3BlYyB1cGRhdGVzDQoNCisxIHRv IHR5cC4NCg0KU28gInR5cCI6ICJzZXQiIG9yICJ0eXAiOiAiZXZlbnQiPw0KDQpPbiBUaHUsIEp1 biAyOSwgMjAxNyBhdCA1OjE3IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KKzEgdG8gdHlwIGNsYWlt Lg0KDQpQaGlsDQoNCk9uIEp1biAyOSwgMjAxNywgYXQgNTowMSBQTSwgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KU29y cnkgZm9yIGEgdGFyZHkgcmVwbHksIGJ1dCArMSBmb3IgdGhlIGJvdGggY2hhbmdlcy4gJ2V4cCcg Y2xhaW0gcmVxdWlyZW1lbnQgaXMgYSBnb29kIHByYWN0aWNhbCBzdGVwIHdpdGggYSBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5Lg0KSGF2aW5nIHNhaWQgdGhhdCwgSSBiZWxpZXZlIGluZmVycmluZyBt ZXNzYWdlIHR5cGVzIGZyb20gdGhlIGV4aXN0ZW5jZS9hYnNlbmNlIG9mIGEgY2xhaW0gaXMgbm90 IGEgZ29vZCBzZWN1cml0eSBwcmFjdGljZS4gSSB3b3VsZCBsaWtlIHRvIHNlZSBhbiBleHBsaWNp dCB0eXBpbmcgdGhyb3VnaCAidHlwIiBjbGFpbSBhZGRlZCBhcyB3ZWxsLg0KDQpOYXQNCg0KT24g RnJpLCBKdW4gMzAsIDIwMTcgYXQgNzowNCBBTSBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KT2suDQoNCkkg c3Bva2Ugd2l0aCBNaWtlIGFuZCBoZSB3aWxsIHBvc3QgaGlzIGNoYW5nZXMgdG8gU0VUIGluIGEg bmV3IHJldmlzaW9uIG92ZXIgdGhlIHdlZWtlbmQuDQoNClBoaWwNCg0KT24gSnVuIDI5LCAyMDE3 LCBhdCAxOjUxIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCkkgdW5kZXJzdGFuZCBpdCBpcyBuZXcgYW5kIHRo YXQgdGhlcmUgaXMgY29udGVudGlvbi4NCg0KV2UgY2xlYXJseSB3YW50IGNvbnNlbnN1cyBmb3Ig dXMgdG8gYmUgZG9uZSB3aXRoIHRoZSBkcmFmdC4gSSB0aGluayBoYXZpbmcgaXQgaW4gdGhlIG5l eHQgZHJhZnQgYW5jaG9ycyB0aGUgZGlzY3Vzc2lvbiBzbyB3ZSBjYW4gZGlzY3VzcyBhbmQgYXJy aXZlIGF0IGNvbnNlbnN1cyBvciBhbiBhbHRlcm5hdGl2ZS4NCg0KU28geWVzLCBpcyBsaWtlIGEg bmV3IGRyYWZ0IHBvc3RlZCBzbyB3ZSBjYW4gZGlzY3Vzcy4NCg0KT24gVGh1LCBKdW4gMjksIDIw MTcgYXQgMTI6NTggUE0gUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkRpY2ssDQoNClRoZSBzZWN0aW9uIGlzIGEgYnJh bmQgbmV3IHNlY3Rpb24uIEl0IHNlZW1zIHRvIG1lIHRoYXQgaGFzIG5vdCBiZWVuIGFueSAob3Ig bGltaXRlZCkgZGlzY3Vzc2lvbiB0byB3YXJyYW50IHB1dHRpbmcgaXQgaW4gdGhlIGRvY3VtZW50 LiAgSXQgY2VydGFpbmx5IGNhbWUgdG8gbWUgYXMgYSBzdXJwcmlzZS4NCg0KSSB0aGluayB0aGUg aXNzdWUgb2YgdHJ1c3QgbW9kZWwgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkLiAgSXQgbWF5IG5vdCBi ZWxvbmcgaGVyZSBhdCBhbGwuDQoNClBsZWFzZSBhZHZpc2UuICBEbyB5b3Ugd2FudCBpdCBwb3N0 ZWQgaW4gc3BpdGUgb2YgY29uc2Vuc3VzPw0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwg SWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0ICYgU3RhbmRhcmRzDQpAaW5kZXBlbmRl bnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01GYVEmYz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdD SDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPUR6aHZfMWFUQWh6c3lRcTFVcENPN3Fp V3h6QUhKWDh5LV9WR0pDM0VBQ2cmcz1mRVZ2RnNFcWtUbUNwWTZzSWFfR1ZfUzNHeTFneGhHNTZX YWJ3MjRHMExBJmU9Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tPg0KDQpPbiBKdW4gMjksIDIwMTcsIGF0IDEyOjI1IFBNLCBEaWNrIEhhcmR0IDxkaWNr LmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0K SGkgUGhpbA0KDQp3cnQgYXNraW5nIGZvciBtb3JlIGRpc2N1c3Npb24sIEkgYXBwcmVjaWF0ZSB5 b3UgbWFraW5nIHRoZSBzdWdnZXN0aW9uIG9uIGJlaGFsZiBvZiB0aGUgY2hhaXJzLiBJdCBkb2Vz IHNlZW0gdGhlcmUgaXMgYSByZWFzb25hYmxlIGFtb3VudCBvZiBkaXNjdXNzaW9uIGdvaW5nIG9u IG5vdyB3b3VsZCB5b3Ugbm90IGFncmVlPw0KDQpJJ2QgbGlrZSB0byBnZXQgdGhlIGRvYyB1cGRh dGVkIGluIHRpbWUgZm9yIFByYWd1ZSBzbyB0aGF0IHdlIGhhdmUgYSBjbGVhciByZWZlcmVuY2Ug cG9pbnQgZm9yIGRpc2N1c3Npb24gdGhlcmUgYW5kIHRoZW4uDQoNClVuY2xlYXIgd2h5IHlvdSB3 b3VsZCBwb3N0IGEgY2hhbmdlIHdoZW4gaXQgd2FzIE1pa2UgdGhhdCBkaWQgdGhpcyB3b3JrLiBB bSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KDQpNaWtlOiB3b3VsZCB5b3UgdXBkYXRlIHRoZSBkb2Mg d2l0aCB3aGF0IHlvdSB0aGluayBpcyByb3VnaCBjb25zZW5zdXMgd2hlbiB5b3UgaGF2ZSB0aW1l IHNvIHRoYXQgd2UgY2FuIGhhdmUgYSBjcmlzcCBkaXNjdXNzaW9uIGluIFByYWd1ZT8NCg0KDQoN Ck9uIFdlZCwgSnVuIDI4LCAyMDE3IGF0IDU6MzggUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpJIGFn cmVlIG9uIHRoZSBleHAgcGFydC4NCg0KUmVnYXJkaW5nIHRoZSBzZWNvbmQgcGFydC4gSSB3b3Vs ZCBsaWtlIHRvIHNlZSBtb3JlIGRpc2N1c3Npb24uDQoNCkZvciBleGFtcGxlLCBpbiB0aGUgdGhl IHVzZSBjYXNlcywgdGhlcmUgbWF5IGJlIGNvbXBhdGliaWxpdHkgaXNzdWVzIGlmIGRpZmZlcmVu dCBzZXQgcHJvZmlsZXMgY2Fubm90IGJlIHNlbnQgb3ZlciB0aGUgc2FtZSBzdHJlYW0uDQoNClN1 Y2ggcHJvZmlsZXMgc2hvdWxkIGF2b2lkIHRoaW5ncyBsaWtlIHJlcXVpcmluZyBzaWduaW5nIGFu ZCBlbmNyeXB0aW9uIHdpdGhvdXQgY29uc2lkZXJhdGlvbiByZWdhcmRpbmcgaG93IHRoZXkgYXJl IHRyYW5zZmVycmVkLiAgQWxzbyBrZXkgbWFuYWdlbWVudCBtaWdodCBiZSBiZXR0ZXIgdGllZCB1 cCBpbiBob3cgdGhlIHN0cmVhbXMgYXJlIG1hbmFnZXMgYmVjYXVzZSB0aGUgbmV0d29yayByZWxh dGlvbnNoaXAgbWF5IGRlZmluZSB0aGUgcmVxdWlyZW1lbnRzIHJhdGhlciB0aGFuIHRoZSBkYXRh Lg0KDQpNeSBpbml0aWFsIHJlYWN0aW9uIGlzLCB0aGUgcHJvZmlsZXMgc2hvdWxkIHN0aWNrIHRv IHRoZSBkYXRhIGFuZCB2YWxpZCBpbnRlcnByZXRhdGlvbi4NCg0KSWYgdGhlIGdyb3VwIGFncmVl cyBJIHdpbGwgbWVyZ2UgdGhlIGV4cCBhbmQgcG9zdCBvdmVyIHRoZSB3ZWVrZW5kLg0KDQpJIGNh biBtZXJnZSB0aGUgc2Vjb25kIHBhcnQgaWYgdGhlcmUgaXMgYSBzdHJvbmcgYWdyZWVtZW50IHRv IGRvIHNvLg0KDQpUaGFua3MhDQoNClBoaWwNCg0KT24gSnVuIDI4LCAyMDE3LCBhdCA1OjI0IFBN LCBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdv b2dsZS5jb20+PiB3cm90ZToNClRoYW5rIHlvdSBNaWtlIGZvciB3b3JraW5nIG9uIHRoaXMuIEkn bSB2ZXJ5IGhhcHB5IHdpdGggdGhlIGNoYW5nZSByZWdhcmRpbmcgdGhlICJleHAiIGNsYWltLCBh bmQgYmVsaWV2ZSBpdCBpcyB0aGUgYmVzdCByZXNvbHV0aW9uIHRvIHRoZSAiSUQgVG9rZW4iIGNv bmZ1c2lvbiBjb25jZXJuLg0KDQpCeSBtYWtpbmcgdGhlICJleHAiIGNsYWltIHRoYXQgaXMgYWxy ZWFkeTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEc2VjZXZlbnQtMkR0b2tlbi0yRDAx LTIzc2VjdGlvbi0yRDIuMSZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1 WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJm09X1hGOTk0elZuMV9BZVMtQ3pTdHFPUWFWUXBzZGpqdmZCeTM1UzBvN3RIMCZzPTVMOXFx SF9ldmtsWC1IakRGOEtrWjJlNWJOYTZmWmMza0pJWEwycWZVV3MmZT0+IE5PVCBSRUNPTU1FTkRF RCBpbiB0aGUgY3VycmVudCBkcmFmdCBhIE1VU1QgTk9ULCB3ZSBjYW4gcHJvdmlkZSB0aGUgSUQg VG9rZW5zIGFuZCBTRVQgdW5pcXVlbmVzcyBndWFyYW50ZWUgdGhhdCBpcyBkZXNpcmVkLCBhbGxv d2luZyB0aGVzZSB0d28gdHlwZXMgb2YgSldUcyB0byBiZSB1c2VkIHdpdGggYSBjb21tb24gaXNz dWVyLiBUaGlzIGFsc28gYWxsb3dzICJzdWIiIHRvIGJlIHVzZWQgZm9yIGl0cyBpbnRlbmRlZCBw dXJwb3NlIChhcyBkZWZpbmVkIGJ5IFJGQzc1MTkpIHdpdGhvdXQgbW9kaWZpY2F0aW9uLCB3aGlj aCBvdGhlciB3b3JraW5nIGdyb3VwcyB0aGF0IHdpc2ggdG8gcHJvZmlsZSBTRVQgaGF2ZSBleHBy ZXNzZWQgYW4gaW50ZXJlc3QgdG8gZG8NCg0KVGhlIGJlbmVmaXQgdGhlIGNvbW11bml0eSB3aWxs IGdhaW4gZnJvbSB0aGUgU0VUIHN0YW5kYXJkIG92ZXJhbGwgaXMgYSBzdGFuZGFyZCB3YXkgdG8g ZXhwcmVzcyBldmVudHMgdGhhdCB3b24ndCBjb25mbGljdCB3aXRoIElEIFRva2VuIChubyAiaXNz IiBwYXJ0aXRpb25pbmcgcmVxdWlyZWQpLiBXaXRoIE1pa2UncyBjaGFuZ2VzIHdlIGFjaGlldmUg dGhhdCwgYW5kIGluIGEgd2F5IHRoYXQgcmV0YWlucyB0aGUgb3JpZ2luYWwgc2ltcGxpY2l0eSwg ZXh0ZW5zaWJpbGl0eSBhbmQgZ2VuZXJhbGl6YWJpbGl0eSBnb2FscyBvZiBTRVQgYnkgbm90IHJl ZGVmaW5pbmcgYW55IG9mIEpXVCdzIHN0YW5kYXJkIGNsYWltcy4NCg0KDQpPbiBXZWQsIEp1biAy OCwgMjAxNyBhdCA1OjA4IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSGkgZm9sa3Ms DQoNCkkgd2FudGVkIHRvIGdpdmUgeW91IGEgaGVhZHMtdXAgYWJvdXQgdHdvIFNFVCBzcGVjIHVw ZGF0ZXMgaW4gdGhlIGN1cnJlbnQgZWRpdG9y4oCZcyBkcmFmdCBiZWZvcmUgdGhleSBhcmUgcHVi bGlzaGVkLg0KDQpUaGUgZmlyc3Qgc29sdmVzIHRoZSBwb3RlbnRpYWwgSUQgVG9rZW4gLyBTRVQg Y29uZnVzaW9uIHByb2JsZW0gYnkgcmVxdWlyaW5nIHRoYXQgU0VUcyBub3QgaW5jbHVkZSBhIHRv cC1sZXZlbCDigJxleHDigJ0gY2xhaW0gd2hlbiBJRCBUb2tlbnMgY291bGQgYWxzbyBiZSBnZW5l cmF0ZWQgYnkgdGhlIHNhbWUgaXNzdWVyLiAgQmVjYXVzZSDigJxleHDigJ0gaXMgYSByZXF1aXJl ZCBJRCBUb2tlbiBjbGFpbSwgU0VUcyB3b3VsZCB0aGVyZWZvcmUgYmUgcmVqZWN0ZWQgYnkgZXhp c3RpbmcgSUQgVG9rZW4gdmFsaWRhdGlvbiBjb2RlLiAgTm90ZSB0aGF0IHRoaXMgc29sdXRpb24g aXMgYWxyZWFkeSByZWNvbW1lbmRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4gIFRoZSBlZGl0b3Li gJlzIGRyYWZ0IHVwZGF0ZSBtYWtlcyB0aGlzIHNvbHV0aW9uIG1hbmRhdG9yeS4gIFRoaXMgcHJv dmlkZXMgYSBzaW1wbGUgYW5kIGR1cmFibGUgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gd2UgYWdy ZWVkIHRvIHNvbHZlIGF0IElFVEYgOTggaW4gQ2hpY2FnbyBhbmQgdGhhdCBoYXMgYmVlbiB0aGUg c3ViamVjdCBvZiBtdWNoIGRpc2N1c3Npb24gc2luY2UuDQoNClRoZSBzZWNvbmQgYWRkcyB0aGUg Zm9sbG93aW5nIG5ldyBzZWN0aW9uOg0KDQpSZXF1aXJlbWVudHMgZm9yIFNFVCBQcm9maWxlcw0K DQpQcm9maWxlIFNwZWNpZmljYXRpb25zIGZvciBTRVRzIGRlZmluZSB0aGUgc3ludGF4IGFuZCBz ZW1hbnRpY3Mgb2YgU0VUcyBjb25mb3JtaW5nIHRvIHRoYXQgU0VUIHByb2ZpbGUgYW5kIHJ1bGVz IGZvciB2YWxpZGF0aW5nIHRob3NlIFNFVHMuIFRoZSBzeW50YXggZGVmaW5lZCBieSBwcm9maWxp bmcgc3BlY2lmaWNhdGlvbnMgaW5jbHVkZXMgd2hhdCBjbGFpbXMgYW5kIGV2ZW50IHBheWxvYWQg dmFsdWVzIGFyZSB1c2VkIGJ5IFNFVHMgdXRpbGl6aW5nIHRoZSBwcm9maWxlLg0KDQpEZWZpbmlu ZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBTRVQgY29udGVudHMgZm9yIFNFVHMgdXRpbGl6aW5nIHRo ZSBwcm9maWxlIGlzIGVxdWFsbHkgaW1wb3J0YW50LiBQb3NzaWJseSBtb3N0IGltcG9ydGFudCBp cyBkZWZpbmluZyB0aGUgcHJvY2VkdXJlcyB1c2VkIHRvIHZhbGlkYXRlIHRoZSBTRVQgaXNzdWVy IGFuZCB0byBvYnRhaW4gdGhlIGtleXMgY29udHJvbGxlZCBieSB0aGUgaXNzdWVyIHRoYXQgd2Vy ZSB1c2VkIGZvciBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJl c2VudGluZyB0aGUgU0VULiBGb3IgaW5zdGFuY2UsIHNvbWUgcHJvZmlsZXMgbWF5IGRlZmluZSBh biBhbGdvcml0aG0gZm9yIHJldHJpZXZpbmcgdGhlIFNFVCBpc3N1ZXIncyBrZXlzIHRoYXQgdXNl cyB0aGUgaXNzIGNsYWltIHZhbHVlIGFzIGl0cyBpbnB1dC4NCg0KUHJvZmlsZSBTcGVjaWZpY2F0 aW9ucyBNVVNUIGNsZWFybHkgc3BlY2lmeSB0aGUgc3RlcHMgdGhhdCBhIHJlY2lwaWVudCBvZiBh IFNFVCB1dGlsaXppbmcgdGhhdCBwcm9maWxlIE1VU1QgcGVyZm9ybSB0byB2YWxpZGF0ZSB0aGF0 IHRoZSBTRVQgaXMgYm90aCBzeW50YWN0aWNhbGx5IGFuZCBzZW1hbnRpY2FsbHkgdmFsaWQuDQoN Ckl04oCZcyBpbmNsdWRlZCB0byBpbmZvcm0gcHJvZmlsZSB3cml0ZXJzIGFib3V0IHdoYXQgdGhl eSBtdXN0IGRvIHRvIGJlIGFibGUgdG8gdXNlIFNFVHMgc2VjdXJlbHkuICBXaGlsZSBtdWNoIG9m IHRoZSBkaXNjdXNzaW9uIGFzIG9mIGxhdGUgaGFzIGJlZW4gYWJvdXQgc3ludGF4LCBzZW1hbnRp Y3MgaXMgZXF1YWxseSBpbXBvcnRhbnQsIGFuZCBtdXN0IGJlIGNvbnNpZGVyZWQgYnkgcHJvZmls ZSB3cml0ZXJzIGFuZCBkZXBsb3llcnMuDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSBuZXcgc2VjdGlv biBjb250YWlucyBvbmx5IHN0YXRlbWVudHMgdGhhdCBhcmUgYWxyZWFkeSBmYWN0dWFsbHkgYWNj dXJhdGUgcmVxdWlyZW1lbnRzIGJ1dCB0aGF0IHdlcmUgcHJldmlvdXNseSB1bnN0YXRlZC4gIFRo ZSBlZGl0b3LigJlzIGRyYWZ0IG1ha2VzIHRoZXNlIHJlcXVpcmVtZW50cyBleHBsaWNpdC4gIEZl ZWRiYWNrIG9uIGhvdyB0byBtYWtlIHRoZXNlIHJlcXVpcmVtZW50cyBldmVuIG1vcmUgY2xlYXIs IGlzIG9mIGNvdXJzZSwgd2VsY29tZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJ Q0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTVi aVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1fWEY5OTR6Vm4xX0FlUy1D elN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJnM9M3MxR0NjLTNnMktVX3BONkh2V1ZIZ1dCSlhz Nk9HUFk4Sy1uRmFxVXhLUSZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxt YWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3 TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09RVRiR0l4UlpMY1FmWVp0 WVVWazZUN0hrd1lHZlh4LTAyd3kzcDQ1b1hHUSZzPWxNU293YkRualVlWEU3ekxwckdIU1BSZ3ha TWhFWnVJcVRrTFRmZ0JOR0UmZT0+DQoNCg0KDQotLQ0KU3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdB UkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2hh cmR0d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm bT1FVGJHSXhSWkxjUWZZWnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdRJnM9M1VkMXYycEdY RHc0NWc5RmttSXd0V280NXpkRkdfTlNnY2pjZjZrSG5FdyZlPT4gbWFpbCBsaXN0IHRvIGxlYXJu IGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiENCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50 QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1 WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJm09RVRiR0l4UlpMY1FmWVp0WVVWazZUN0hrd1lHZlh4LTAyd3kzcDQ1b1hHUSZzPWxNU293 YkRualVlWEU3ekxwckdIU1BSZ3haTWhFWnVJcVRrTFRmZ0JOR0UmZT0NCg0KLS0NClN1YnNjcmli ZSB0byB0aGUgSEFSRFRXQVJFPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6 ald3bE5LZTRDX2xMSUdrJm09RHpodl8xYVRBaHpzeVFxMVVwQ083cWlXeHpBSEpYOHktX1ZHSkMz RUFDZyZzPWZLOFJYbjAxYWl4b1lzQ2xra3VkZ0pHRXhIMGRkdjZDdjNLWEZZNFB0QzAmZT0+IG1h aWwgbGlzdCB0byBsZWFybiBhYm91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGlu ZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJm09bEZpOXgzWHpoQjFPSHdoVm5tSDJhcmlkVzEtdzFUVGNIQjJIbWVrY3JqTSZz PWxkMGxpNGRxYWo2UzhtdUdzeHBCY0hCY1kxUGx5TEJMSi1UY3lFcnF6MDgmZT0+DQotLQ0KDQpO YXQgU2FraW11cmENCg0KQ2hhaXJtYW4gb2YgdGhlIEJvYXJkLCBPcGVuSUQgRm91bmRhdGlvbg0K DQo= --_000_CY4PR21MB0504A02DFC0137D090C50AEAF5D30CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLm0yMDky NzAzODA3MDkzMDY0NTEwaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fMjA5MjcwMzgwNzA5MzA2 NDUxMGhvZW56Yjt9DQpzcGFuLm0yMDkyNzAzODA3MDkzMDY0NTEwbS0zNzkyMjkxMjExNjAxMzg5 NDM3bTU4MTU4OTk2MzY2MDIxNTg5MDRtLTcyODYxMjcyNzU3OTgyMDE0MmFwcGxlLXN0eWxlLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6bV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYw MTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0MmFwcGxlLXN0 eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2 MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5UaGVyZSBoYWQgYWxyZWFkeSBiZWVuIGRpc2N1c3Npb25zLCBib3RoIGluIENoaWNhZ28sIGFu ZCBpbiB0aGUgSldUIEJDUCBjb250ZXh0LCB0aGF0IGlmIHdlIHdlcmUgZ29pbmcgdG8gdXNlIGEg dHlwZSBpZGVudGlmaWVyLCB3ZSB3b3VsZCB1c2UgdGhlIGV4aXN0aW5nIOKAnHR5cOKAnSBoZWFk ZXIgcGFyYW1ldGVyIGFuZCBub3QgY3JlYXRlIGEgbmV3IGNsYWltLiZuYnNwOyBUaGlzDQogaXMg YSBNSU1FIHR5cGUsIHdpdGggdGhlIGFiaWxpdHkgdG8gb21pdCDigJxhcHBsaWNhdGlvbi/igJ0g Zm9yIHNwYWNlIHJlYXNvbnMsIGlmIGRlc2lyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj5TaW5jZSB0aGVyZSBhcHBlYXJzIHRvIGJlIGJyb2FkIGludGVyZXN0IGluIGhh dmluZyB0aGUgYWJpbGl0eSB0byB1c2UgZXhwbGljaXQgdHlwaW5nIG9mIHRoZSBTRVQsIEkgd2ls bCBwbGFuIHRvIGRlZmluZSB0aGUg4oCcYXBwbGljYXRpb24vc2VjZXZlbnQmIzQzO2p3dOKAnSBN SU1FIHR5cGUgaW4gdGhlIFNFVCBkcmFmdCBiZWZvcmUgcHVibGlzaGluZy4mbmJzcDsgU0VUcyBj b3VsZA0KIHRoZW4gaW5jbHVkZSB0aGUg4oCcdHlw4oCdOuKAnHNlY2V2ZW50JiM0Mztqd3TigJ0g aGVhZGVyIHBhcmFtZXRlciB2YWx1ZSB0byBwcm92aWRlIGV4cGxpY2l0IHR5cGluZy4mbmJzcDsg VW5sZXNzIEkgaGVhciBvYmplY3Rpb25zIHNvb24sIEkgd2lsbCBwcm9jZWVkIG9uIHRoaXMgYmFz aXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdv b2dsZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMzAsIDIwMTcgOTozMyBB TTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50IChJRE0pICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29t Jmd0OzsgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7OyBNaWtlIEpvbmVz ICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBpZC1ldmVudEBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkLWV2ZW50XSBIZWFkcy11cCBhYm91dCBTRVQgc3Bl YyB1cGRhdGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgdG8gdHlwLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gJnF1b3Q7dHlw JnF1b3Q7OiAmcXVvdDtzZXQmcXVvdDsgb3IgJnF1b3Q7dHlwJnF1b3Q7OiAmcXVvdDtldmVudCZx dW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgSnVuIDI5LCAyMDE3IGF0IDU6MTcgUE0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byB0eXAgY2xhaW0uJm5ic3A7 PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJtMjA5 MjcwMzgwNzA5MzA2NDUxMGhvZW56YiI+UGhpbDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVuIDI5LCAyMDE3LCBhdCA1OjAxIFBN LCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5 IGZvciBhIHRhcmR5IHJlcGx5LCBidXQmbmJzcDsmIzQzOzEgZm9yIHRoZSBib3RoIGNoYW5nZXMu ICdleHAnIGNsYWltIHJlcXVpcmVtZW50IGlzIGEgZ29vZCBwcmFjdGljYWwgc3RlcCB3aXRoIGEg YmFja3dhcmQgY29tcGF0aWJpbGl0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IYXZpbmcgc2FpZCB0aGF0LCBJIGJlbGlldmUgaW5mZXJyaW5nIG1l c3NhZ2UgdHlwZXMgZnJvbSB0aGUgZXhpc3RlbmNlL2Fic2VuY2Ugb2YgYSBjbGFpbSBpcyBub3Qg YSBnb29kIHNlY3VyaXR5IHByYWN0aWNlLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGFuIGV4cGxpY2l0 IHR5cGluZyB0aHJvdWdoICZxdW90O3R5cCZxdW90OyBjbGFpbSBhZGRlZCBhcyB3ZWxsLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O YXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBKdW4gMzAsIDIwMTcgYXQgNzowNCBBTSBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVu dEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzky MjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0QXBwbGVNYWlsU2lnbmF0dXJlIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5 NjM2NjAyMTU4OTA0QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg c3Bva2Ugd2l0aCBNaWtlIGFuZCBoZSB3aWxsIHBvc3QgaGlzIGNoYW5nZXMgdG8gU0VUIGluIGEg bmV3IHJldmlzaW9uIG92ZXIgdGhlIHdlZWtlbmQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIy OTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRBcHBsZU1haWxTaWduYXR1cmUiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2 MzY2MDIxNTg5MDRBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhp bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4gMjks IDIwMTcsIGF0IDE6NTEgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0YW5kIGl0IGlzIG5ldyBhbmQgdGhhdCB0aGVy ZSBpcyBjb250ZW50aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjbGVhcmx5IHdhbnQgY29uc2Vuc3VzIGZvciB1cyB0byBi ZSBkb25lIHdpdGggdGhlIGRyYWZ0LiBJIHRoaW5rIGhhdmluZyBpdCBpbiB0aGUgbmV4dCBkcmFm dCBhbmNob3JzIHRoZSBkaXNjdXNzaW9uIHNvIHdlIGNhbiBkaXNjdXNzIGFuZCBhcnJpdmUgYXQg Y29uc2Vuc3VzIG9yIGFuIGFsdGVybmF0aXZlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB5ZXMsIGlzIGxpa2UgYSBuZXcgZHJh ZnQgcG9zdGVkIHNvIHdlIGNhbiBkaXNjdXNzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gMjksIDIwMTcgYXQgMTI6NTggUE0g UGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EaWNrLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgc2VjdGlvbiBpcyBhIGJyYW5kIG5ldyBzZWN0aW9uLiBJdCBzZWVtcyB0byBt ZSB0aGF0IGhhcyBub3QgYmVlbiBhbnkgKG9yIGxpbWl0ZWQpIGRpc2N1c3Npb24gdG8gd2FycmFu dCBwdXR0aW5nIGl0IGluIHRoZSBkb2N1bWVudC4mbmJzcDsgSXQgY2VydGFpbmx5IGNhbWUgdG8g bWUgYXMgYSBzdXJwcmlzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgaXNzdWUgb2YgdHJ1c3QgbW9kZWwgbmVlZHMgdG8g YmUgZGlzY3Vzc2VkLiZuYnNwOyBJdCBtYXkgbm90IGJlbG9uZyBoZXJlIGF0IGFsbC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGFk dmlzZS4mbmJzcDsgRG8geW91IHdhbnQgaXQgcG9zdGVkIGluIHNwaXRlIG9mIGNvbnNlbnN1cz88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T3Jh Y2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QgJmFtcDsg U3RhbmRhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZhbXA7ZD1E d01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZh bXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUR6 aHZfMWFUQWh6c3lRcTFVcENPN3FpV3h6QUhKWDh5LV9WR0pDM0VBQ2cmYW1wO3M9ZkVWdkZzRXFr VG1DcFk2c0lhX0dWX1MzR3kxZ3hoRzU2V2FidzI0RzBMQSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDI5 LCAyMDE3LCBhdCAxMjoyNSBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgUGhpbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+d3J0IGFza2luZyBmb3IgbW9yZSBkaXNjdXNzaW9uLCBJIGFwcHJlY2lhdGUgeW91IG1ha2lu ZyB0aGUgc3VnZ2VzdGlvbiBvbiBiZWhhbGYgb2YgdGhlIGNoYWlycy4gSXQgZG9lcyBzZWVtIHRo ZXJlIGlzIGEgcmVhc29uYWJsZSBhbW91bnQgb2YgZGlzY3Vzc2lvbiBnb2luZyBvbiBub3cgd291 bGQgeW91IG5vdCBhZ3JlZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSdkIGxpa2UgdG8gZ2V0IHRoZSBkb2MgdXBkYXRlZCBpbiB0aW1lIGZv ciBQcmFndWUgc28gdGhhdCB3ZSBoYXZlIGEgY2xlYXIgcmVmZXJlbmNlIHBvaW50IGZvciBkaXNj dXNzaW9uIHRoZXJlIGFuZCB0aGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5jbGVhciB3aHkgeW91IHdvdWxkIHBvc3QgYSBj aGFuZ2Ugd2hlbiBpdCB3YXMgTWlrZSB0aGF0IGRpZCB0aGlzIHdvcmsuIEFtIEkgbWlzc2luZyBz b21ldGhpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1pa2U6IHdvdWxkIHlvdSB1cGRhdGUgdGhlIGRvYyB3aXRoIHdoYXQgeW91IHRoaW5r IGlzIHJvdWdoIGNvbnNlbnN1cyB3aGVuIHlvdSBoYXZlIHRpbWUgc28gdGhhdCB3ZSBjYW4gaGF2 ZSBhIGNyaXNwIGRpc2N1c3Npb24gaW4gUHJhZ3VlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biAyOCwg MjAxNyBhdCA1OjM4IFBNLCBQaGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIG9uIHRoZSBleHAgcGFydC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5 MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1f LTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgw NzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03 Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJl Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcnQuIEkgd291 bGQgbGlrZSB0byBzZWUgbW9yZSBkaXNjdXNzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3 bV81ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1 OTczODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0NTEwbV8t Mzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgy MDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGluIHRoZSB0aGUgdXNlIGNhc2VzLCB0aGVyZSBtYXkg YmUgY29tcGF0aWJpbGl0eSBpc3N1ZXMgaWYgZGlmZmVyZW50IHNldCBwcm9maWxlcyBjYW5ub3Qg YmUgc2VudCBvdmVyIHRoZSBzYW1lIHN0cmVhbS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21f NTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3 MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3 OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAx NDJtXy0yNDY3OTk5MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlN1Y2ggcHJvZmlsZXMgc2hvdWxkIGF2b2lkIHRoaW5ncyBsaWtlIHJlcXVpcmlu ZyBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIHdpdGhvdXQgY29uc2lkZXJhdGlvbiByZWdhcmRpbmcg aG93IHRoZXkgYXJlIHRyYW5zZmVycmVkLiZuYnNwOyBBbHNvIGtleSBtYW5hZ2VtZW50IG1pZ2h0 IGJlIGJldHRlciB0aWVkIHVwIGluIGhvdyB0aGUgc3RyZWFtcyBhcmUgbWFuYWdlcyBiZWNhdXNl IHRoZSBuZXR3b3JrIHJlbGF0aW9uc2hpcA0KIG1heSBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyBy YXRoZXIgdGhhbiB0aGUgZGF0YS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0ibV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYz NjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBs ZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2 MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3 OTk5MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk15IGluaXRpYWwgcmVhY3Rpb24gaXMsIHRoZSBwcm9maWxlcyBzaG91bGQgc3RpY2sgdG8gdGhl IGRhdGEgYW5kIHZhbGlkIGludGVycHJldGF0aW9uLiZuYnNwOzxicj4NCjxicj4NCklmIHRoZSBn cm91cCBhZ3JlZXMgSSB3aWxsIG1lcmdlIHRoZSBleHAgYW5kIHBvc3Qgb3ZlciB0aGUgd2Vla2Vu ZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkz MDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYx MjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2 MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTkyMTU5NzM4MjkwQXBw bGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIG1lcmdlIHRoZSBz ZWNvbmQgcGFydCBpZiB0aGVyZSBpcyBhIHN0cm9uZyBhZ3JlZW1lbnQgdG8gZG8gc28uJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1f LTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4 MjAxNDJtXy0yNDY3OTk5MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIw OTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4 OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTczODI5MEFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0 MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTky MTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N ClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4g MjgsIDIwMTcsIGF0IDU6MjQgUE0sIFdpbGxpYW0gRGVubmlzcyAmbHQ7PGEgaHJlZj0ibWFpbHRv OndkZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53ZGVubmlzc0Bnb29nbGUuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IE1pa2UgZm9yIHdvcmtpbmcgb24g dGhpcy4gSSdtIHZlcnkgaGFwcHkgd2l0aCB0aGUgY2hhbmdlIHJlZ2FyZGluZyB0aGUgJnF1b3Q7 ZXhwJnF1b3Q7IGNsYWltLCBhbmQgYmVsaWV2ZSBpdCBpcyB0aGUgYmVzdCByZXNvbHV0aW9uIHRv IHRoZSAmcXVvdDtJRCBUb2tlbiZxdW90OyBjb25mdXNpb24gY29uY2Vybi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnkgbWFraW5nIHRoZSAm cXVvdDtleHAmcXVvdDsgY2xhaW0gdGhhdCBpcyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJh ZnQtMkRpZXRmLTJEc2VjZXZlbnQtMkR0b2tlbi0yRDAxLTIzc2VjdGlvbi0yRDIuMSZhbXA7ZD1E d01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZh bXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPV9Y Rjk5NHpWbjFfQWVTLUN6U3RxT1FhVlFwc2RqanZmQnkzNVMwbzd0SDAmYW1wO3M9NUw5cXFIX2V2 a2xYLUhqREY4S2taMmU1Yk5hNmZaYzNrSklYTDJxZlVXcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij4NCmFscmVhZHk8L2E+IE5PVCBSRUNPTU1FTkRFRCBpbiB0aGUgY3VycmVudCBkcmFmdCBhIE1V U1QgTk9ULCB3ZSBjYW4gcHJvdmlkZSB0aGUgSUQgVG9rZW5zIGFuZCBTRVQgdW5pcXVlbmVzcyBn dWFyYW50ZWUgdGhhdCBpcyBkZXNpcmVkLCBhbGxvd2luZyB0aGVzZSB0d28gdHlwZXMgb2YgSldU cyB0byBiZSB1c2VkIHdpdGggYSBjb21tb24gaXNzdWVyLiBUaGlzIGFsc28gYWxsb3dzICZxdW90 O3N1YiZxdW90OyB0byBiZSB1c2VkIGZvciBpdHMgaW50ZW5kZWQgcHVycG9zZQ0KIChhcyBkZWZp bmVkIGJ5IFJGQzc1MTkpIHdpdGhvdXQgbW9kaWZpY2F0aW9uLCB3aGljaCBvdGhlciB3b3JraW5n IGdyb3VwcyB0aGF0IHdpc2ggdG8gcHJvZmlsZSBTRVQgaGF2ZSBleHByZXNzZWQgYW4gaW50ZXJl c3QgdG8gZG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGJlbmVmaXQgdGhlIGNvbW11bml0eSB3aWxsIGdhaW4gZnJvbSB0aGUgU0VUIHN0 YW5kYXJkIG92ZXJhbGwgaXMgYSBzdGFuZGFyZCB3YXkgdG8gZXhwcmVzcyBldmVudHMgdGhhdCB3 b24ndCBjb25mbGljdCB3aXRoIElEIFRva2VuIChubyAmcXVvdDtpc3MmcXVvdDsgcGFydGl0aW9u aW5nIHJlcXVpcmVkKS4gV2l0aCBNaWtlJ3MgY2hhbmdlcyB3ZSBhY2hpZXZlIHRoYXQsIGFuZCBp biBhIHdheSB0aGF0IHJldGFpbnMgdGhlDQogb3JpZ2luYWwgc2ltcGxpY2l0eSwgZXh0ZW5zaWJp bGl0eSBhbmQgZ2VuZXJhbGl6YWJpbGl0eSBnb2FscyBvZiBTRVQgYnkgbm90IHJlZGVmaW5pbmcg YW55IG9mIEpXVCdzIHN0YW5kYXJkIGNsYWltcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biAyOCwgMjAxNyBhdCA1OjA4 IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSB3YW50ZWQgdG8gZ2l2ZSB5b3UgYSBoZWFkcy11cCBhYm91dCB0d28gU0VUIHNwZWMgdXBkYXRl cyBpbiB0aGUgY3VycmVudCBlZGl0b3LigJlzIGRyYWZ0IGJlZm9yZSB0aGV5IGFyZSBwdWJsaXNo ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZmlyc3Qgc29sdmVzIHRoZSBwb3Rl bnRpYWwgSUQgVG9rZW4gLyBTRVQgY29uZnVzaW9uIHByb2JsZW0gYnkgcmVxdWlyaW5nIHRoYXQg U0VUcyBub3QgaW5jbHVkZSBhIHRvcC1sZXZlbCDigJxleHDigJ0gY2xhaW0gd2hlbiBJRCBUb2tl bnMgY291bGQgYWxzbyBiZSBnZW5lcmF0ZWQgYnkgdGhlIHNhbWUgaXNzdWVyLiZuYnNwOw0KIEJl Y2F1c2Ug4oCcZXhw4oCdIGlzIGEgcmVxdWlyZWQgSUQgVG9rZW4gY2xhaW0sIFNFVHMgd291bGQg dGhlcmVmb3JlIGJlIHJlamVjdGVkIGJ5IGV4aXN0aW5nIElEIFRva2VuIHZhbGlkYXRpb24gY29k ZS4mbmJzcDsgTm90ZSB0aGF0IHRoaXMgc29sdXRpb24gaXMgYWxyZWFkeSByZWNvbW1lbmRlZCBp biB0aGUgc3BlY2lmaWNhdGlvbi4mbmJzcDsgVGhlIGVkaXRvcuKAmXMgZHJhZnQgdXBkYXRlIG1h a2VzIHRoaXMgc29sdXRpb24gbWFuZGF0b3J5LiZuYnNwOyBUaGlzIHByb3ZpZGVzDQogYSBzaW1w bGUgYW5kIGR1cmFibGUgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gd2UgYWdyZWVkIHRvIHNvbHZl IGF0IElFVEYgOTggaW4gQ2hpY2FnbyBhbmQgdGhhdCBoYXMgYmVlbiB0aGUgc3ViamVjdCBvZiBt dWNoIGRpc2N1c3Npb24gc2luY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgc2Vj b25kIGFkZHMgdGhlIGZvbGxvd2luZyBuZXcgc2VjdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBwdDtt YXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+UmVxdWlyZW1l bnRzIGZvciBTRVQgUHJvZmlsZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBw dDttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWxlZnQ6MjQuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlByb2ZpbGUgU3BlY2lmaWNhdGlvbnMgZm9y IFNFVHMgZGVmaW5lIHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIGNvbmZvcm1pbmcg dG8gdGhhdCBTRVQgcHJvZmlsZSBhbmQgcnVsZXMgZm9yIHZhbGlkYXRpbmcgdGhvc2UgU0VUcy4g VGhlIHN5bnRheCBkZWZpbmVkIGJ5IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucw0KIGluY2x1ZGVz IHdoYXQgY2xhaW1zIGFuZCBldmVudCBwYXlsb2FkIHZhbHVlcyBhcmUgdXNlZCBieSBTRVRzIHV0 aWxpemluZyB0aGUgcHJvZmlsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBw dDttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWxlZnQ6MjQuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkRlZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2Yg dGhlIFNFVCBjb250ZW50cyBmb3IgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUgaXMgZXF1YWxs eSBpbXBvcnRhbnQuIFBvc3NpYmx5IG1vc3QgaW1wb3J0YW50IGlzIGRlZmluaW5nIHRoZSBwcm9j ZWR1cmVzIHVzZWQgdG8gdmFsaWRhdGUgdGhlIFNFVCBpc3N1ZXIgYW5kDQogdG8gb2J0YWluIHRo ZSBrZXlzIGNvbnRyb2xsZWQgYnkgdGhlIGlzc3VlciB0aGF0IHdlcmUgdXNlZCBmb3IgY3J5cHRv Z3JhcGhpYyBvcGVyYXRpb25zIHVzZWQgaW4gdGhlIEpXVCByZXByZXNlbnRpbmcgdGhlIFNFVC4g Rm9yIGluc3RhbmNlLCBzb21lIHByb2ZpbGVzIG1heSBkZWZpbmUgYW4gYWxnb3JpdGhtIGZvciBy ZXRyaWV2aW5nIHRoZSBTRVQgaXNzdWVyJ3Mga2V5cyB0aGF0IHVzZXMgdGhlDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5pc3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+IGNs YWltIHZhbHVlIGFzIGl0cyBpbnB1dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0 LjBwdDttYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWxlZnQ6MjQu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlByb2ZpbGUgU3BlY2lmaWNhdGlvbnMg TVVTVCBjbGVhcmx5IHNwZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYSByZWNpcGllbnQgb2YgYSBTRVQg dXRpbGl6aW5nIHRoYXQgcHJvZmlsZSBNVVNUIHBlcmZvcm0gdG8gdmFsaWRhdGUgdGhhdCB0aGUg U0VUIGlzIGJvdGggc3ludGFjdGljYWxseSBhbmQgc2VtYW50aWNhbGx5IHZhbGlkLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXTigJlzIGluY2x1ZGVkIHRvIGluZm9ybSBw cm9maWxlIHdyaXRlcnMgYWJvdXQgd2hhdCB0aGV5IG11c3QgZG8gdG8gYmUgYWJsZSB0byB1c2Ug U0VUcyBzZWN1cmVseS4mbmJzcDsgV2hpbGUgbXVjaCBvZiB0aGUgZGlzY3Vzc2lvbiBhcyBvZiBs YXRlIGhhcyBiZWVuIGFib3V0IHN5bnRheCwgc2VtYW50aWNzIGlzIGVxdWFsbHkNCiBpbXBvcnRh bnQsIGFuZCBtdXN0IGJlIGNvbnNpZGVyZWQgYnkgcHJvZmlsZSB3cml0ZXJzIGFuZCBkZXBsb3ll cnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGJlbGlldmUgdGhhdCB0aGUgbmV3IHNl Y3Rpb24gY29udGFpbnMgb25seSBzdGF0ZW1lbnRzIHRoYXQgYXJlIGFscmVhZHkgZmFjdHVhbGx5 IGFjY3VyYXRlIHJlcXVpcmVtZW50cyBidXQgdGhhdCB3ZXJlIHByZXZpb3VzbHkgdW5zdGF0ZWQu Jm5ic3A7IFRoZSBlZGl0b3LigJlzIGRyYWZ0IG1ha2VzIHRoZXNlIHJlcXVpcmVtZW50cw0KIGV4 cGxpY2l0LiZuYnNwOyBGZWVkYmFjayBvbiBob3cgdG8gbWFrZSB0aGVzZSByZXF1aXJlbWVudHMg ZXZlbiBtb3JlIGNsZWFyLCBpcyBvZiBjb3Vyc2UsIHdlbGNvbWVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lz aGVzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVu dCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kw NTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdr JmFtcDttPV9YRjk5NHpWbjFfQWVTLUN6U3RxT1FhVlFwc2RqanZmQnkzNVMwbzd0SDAmYW1wO3M9 M3MxR0NjLTNnMktVX3BONkh2V1ZIZ1dCSlhzNk9HUFk4Sy1uRmFxVXhLUSZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJ Q0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1w O3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1fWEY5 OTR6Vm4xX0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTNzMUdDYy0zZzJL VV9wTjZIdldWSGdXQkpYczZPR1BZOEstbkZhcVV4S1EmYW1wO2U9PC9hPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2 ZW50QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktD WDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5L ZTRDX2xMSUdrJmFtcDttPUVUYkdJeFJaTGNRZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9Y R1EmYW1wO3M9bE1Tb3diRG5qVWVYRTd6THByR0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZhbXA7 ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkLWV2ZW50PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWJzY3Jp YmUgdG8gdGhlIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZr SVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUVUYkdJeFJaTGNRZlladFlVVms2VDdI a3dZR2ZYeC0wMnd5M3A0NW9YR1EmYW1wO3M9M1VkMXYycEdYRHc0NWc5RmttSXd0V280NXpkRkdf TlNnY2pjZjZrSG5FdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCkhBUkRUV0FSRTwvYT4gbWFp bCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JZC1ldmVudEBpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1Ni SzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1w O209RVRiR0l4UlpMY1FmWVp0WVVWazZUN0hrd1lHZlh4LTAyd3kzcDQ1b1hHUSZhbXA7cz1sTVNv d2JEbmpVZVhFN3pMcHJHSFNQUmd4Wk1oRVp1SXFUa0xUZmdCTkdFJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcm YW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1K Qm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUVUYkdJeFJa TGNRZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9YR1EmYW1wO3M9bE1Tb3diRG5qVWVYRTd6 THByR0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZhbXA7ZT08L2E+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TdWJzY3JpYmUgdG8gdGhlIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1E d01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZh bXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUR6 aHZfMWFUQWh6c3lRcTFVcENPN3FpV3h6QUhKWDh5LV9WR0pDM0VBQ2cmYW1wO3M9Zks4UlhuMDFh aXhvWXNDbGtrdWRnSkdFeEgwZGR2NkN2M0tYRlk0UHRDMCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij4NCkhBUkRUV0FSRTwvYT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0g d29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1l dmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklkLWV2ZW50QGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed01G YVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7 cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPWxGaTl4 M1h6aEIxT0h3aFZubUgyYXJpZFcxLXcxVFRjSEIySG1la2Nyak0mYW1wO3M9bGQwbGk0ZHFhajZT OG11R3N4cEJjSEJjWTFQbHlMQkxKLVRjeUVycXowOCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD5OYXQgU2FraW11cmE8bzpw PjwvbzpwPjwvcD4NCjxwPkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_CY4PR21MB0504A02DFC0137D090C50AEAF5D30CY4PR21MB0504namp_-- From nobody Fri Jun 30 13:35:38 2017 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAC9128BC8; Fri, 30 Jun 2017 13:35:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149885493093.4630.876399517369117002@ietfa.amsl.com> Date: Fri, 30 Jun 2017 13:35:30 -0700 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-token-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 20:35:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events of the IETF. Title : Security Event Token (SET) Authors : Phil Hunt William Denniss Morteza Ansari Michael B. Jones Filename : draft-ietf-secevent-token-02.txt Pages : 23 Date : 2017-06-30 Abstract: This specification defines the Security Event Token, which may be distributed via a protocol such as HTTP. The Security Event Token (SET) specification profiles the JSON Web Token (JWT), which can be optionally signed and/or encrypted. A SET describes a statement of fact from the perspective of an issuer that it intends to share with one or more receivers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-token-02 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-token-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-token-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 30 13:40:22 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C19131500 for ; Fri, 30 Jun 2017 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXOhPyxGGFUJ for ; Fri, 30 Jun 2017 13:40:19 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0106.outbound.protection.outlook.com [104.47.40.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3A11314FE for ; Fri, 30 Jun 2017 13:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pU0Zh1wp50Y2/pNEHok7XNBSSAGGiD+dUdK3dJoKT6k=; b=kox1SXgMDrNr2opZtB5s0kuGrBimFPAwFuPI+QNqSKI4zlDtF5iEw5Th3rkHDgNCi5ccUZNKG1iA8cQoBrY82dbDjZmSuPvnPhbMXUpObRZh1tFagVsybvCD3/EQ9hZbeRwr95E7QLcWy7K9aBGLq362gmOSQrBA71F9Q34jbIM= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0184.namprd21.prod.outlook.com (10.173.193.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.2; Fri, 30 Jun 2017 20:40:17 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 20:40:17 +0000 From: Mike Jones To: "id-event@ietf.org" Thread-Topic: Security Event Token (SET) specification preventing token confusion Thread-Index: AdLx3AUuYtk5ni5STf+FQ35o4MpF4w== Date: Fri, 30 Jun 2017 20:40:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-30T13:40:16.3197935-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0184; 7:D7ZbuXfX6VYfBLACD/4bIwSG7ZlvddOndfQmvsy1Qkbjz9jI78MN3h+R+3hERBpz+EqRWtWAic4JMQejI+oH+SogWxyISRy/acogXoL8t02rTNJ0eezAoFZf26NpjdioOetvFksgkltDf/QF2cyvj2NKPZsVlFDBe5Cpp6xrkBe8L14rrxqL/cCoEmrW95G2VL2trtJnZOl+k8Me1kh5LV5hsSKIfKCIFKFcrsaOMN8RPLU7cTWrscV1YNMCUBIu4tnzX9CssMziwi82zFRDpx+7Gjsz5duVt6NwmZRA3AuWm+czZzOsKgyoqy0wr9v4aOFzg1lhTMaWEf07ccaIvEngarTubo/DtYyzbQTPL75qe2xQoEXd4V+ZrSCe/QjS5lnvaFgd5+mwDYMDDO3l03hZ/QfgaGvY5DzUGz5hNLM59HRieohpv/V8ty3Paj6gVUP1u3/KUJzhnk+HxUZ1zN+Cbyy3DiqAJdOGKjm8+y5OhKcCtSd1nsfTkG5guhQJIMp/1ODN41oRCLHIGRdfWXIfYj572c2ZfC2CbBM7TBIRFC9rclPxz6KRAhn7nitkhpcLN8SicVNaGuPjAXR0jSBbhRW6IqpMu+mq3EtmLZOns66OWAPqRINwau9b1soQomuV4RyKiY1jrgEjM2mTx1GSDszI7HofZ9mYQDYwMPpMzzQkAcmD+8pt1sDzlqzGWCUC61jXuK+wE5lfYjjSsJ//Yc0yOOcmt+NUIl47EWY3veylVS4rvWfAGjjg2Hx0vsSWBuCISae63wX0JQ/nVMOpmHB2B22sbzZa+PhGH8HcmkCBA6/Qs0hU+UzOsgAk x-ms-office365-filtering-correlation-id: e32a9a8b-df1f-416b-a147-08d4bff8380b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0184; x-ms-traffictypediagnostic: CY4PR21MB0184: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(192374486261705)(31418570063057)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910020)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0184; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0184; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39400400002)(39850400002)(39840400002)(39860400002)(209900001)(69224002)(478600001)(2501003)(7736002)(606006)(38730400002)(53376002)(2351001)(110136004)(7110500001)(189998001)(77096006)(966005)(14454004)(39060400002)(10290500003)(8676002)(81166006)(8936002)(33656002)(72206003)(9686003)(236005)(54896002)(10090500001)(86612001)(99286003)(6306002)(55016002)(6916009)(3660700001)(3280700002)(6506006)(2906002)(2420400007)(53936002)(8990500004)(7696004)(50986999)(790700001)(102836003)(15650500001)(5630700001)(25786009)(5005710100001)(2900100001)(74316002)(5660300001)(6116002)(5640700003)(54356999)(86362001)(6436002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0184; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504B73DD6E90ABE714320BEF5D30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 20:40:17.7191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0184 Archived-At: Subject: [Id-event] Security Event Token (SET) specification preventing token confusion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 20:40:21 -0000 --_000_CY4PR21MB0504B73DD6E90ABE714320BEF5D30CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new version of the Security Event Token (SET) specification has been publ= ished containing measures that prevent any possibility of confusion between= ID Tokens and SETs. Preventing confusion between SETs, access tokens, and= other kinds of JWTs is also covered. Changes were: * Added the Requirements for SET Profiles section. * Expanded the Security Considerations section to describe how to preve= nt confusion of SETs with ID Tokens, access tokens, and other kinds of JWTs= . * Registered the application/secevent+jwt media type and defined how to= use it for explicit typing of SETs. * Clarified the misleading statement that used to say that a SET convey= s a single security event. * Added a note explicitly acknowledging that some SET profiles may choo= se to convey event subject information in the event payload. * Corrected an encoded claims set example. * Applied grammar corrections. This draft is intended to provide solutions to the issues that had been dis= cussed in IETF 98 in Chicago and subsequently on the working group mailing = list. Thanks for all the great discussions that informed this draft! The specification is available at: * https://tools.ietf.org/html/draft-ietf-secevent-token-02 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-secevent-token-02.html -- Mike P.S. This announcement was also posted at http://self-issued.info/?p=3D170= 9 and as @selfissued. --_000_CY4PR21MB0504B73DD6E90ABE714320BEF5D30CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new version of the Security Event Token (SET) spec= ification has been published containing measures that prevent any possibili= ty of confusion between ID Tokens and SETs.  Preventing confusion betw= een SETs, access tokens, and other kinds of JWTs is also covered.  Changes were:

  • Added the Requirements for SET Profiles section.
  • Expanded the Security Considerations section to describe how to prevent co= nfusion of SETs with ID Tokens, access tokens, and other kinds of JWTs.
  • Registered the application/secevent= 3;jwt media type and defined how to use it for explicit typing of SE= Ts.
  • Clarified the misleading statement that used to sa= y that a SET conveys a single security event.
  • Added a = note explicitly acknowledging that some SET profiles may choose to convey e= vent subject information in the event payload.
  • Correct= ed an encoded claims set example.
  • Applied grammar corr= ections.

 

This draft is intended to provide solutions to the i= ssues that had been discussed in IETF 98 in Chicago and subsequently on the= working group mailing list.  Thanks for all the great discussions tha= t informed this draft!

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

P.S.  This announcement was also posted at http://self-issued.info/?p=3D1709 and as @selfissued.

--_000_CY4PR21MB0504B73DD6E90ABE714320BEF5D30CY4PR21MB0504namp_-- From nobody Fri Jun 30 13:49:20 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686EF129B61 for ; Fri, 30 Jun 2017 13:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEdGOVdy1_nb for ; Fri, 30 Jun 2017 13:49:16 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E23A12741D for ; Fri, 30 Jun 2017 13:49:16 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p21so110450071qke.3 for ; Fri, 30 Jun 2017 13:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y8ygSwxomrUpuaZg1KmXQYxudZ4zaBU1EzrhCCok/iw=; b=AxDLbWlJxom5oh6u7Xv8lYdXkw8nBTmFJwLA7FLesx8Dm/2wZ1UR5DO7dFqZX/wjgz qsEMdqZbcnt0rIkaDnMaWf2m0RgkCA4J7rpYf4GA/Ku3KE1JBkk+YfI3bnLUrNex0kpE PC5qelPJk+7C3TdxfV0QW1CbbSTsizUA95nMvWup+hR+J3n4ARHXpiE6CyZiD6sw7m5V eckxTnMiGFyIpL61/j+VxOr5vnODKovjPnQ7qLgTYztruEvLBHVM/zAfGjZfGB1raPPK uBuH3mO9yVZKoPrIcbwjLvb9FXmCmLntn4Lp1lC9iGNnvsBS8THDj6/V2xqwMfDY7YYg gzxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y8ygSwxomrUpuaZg1KmXQYxudZ4zaBU1EzrhCCok/iw=; b=kHutO97Sd7yrPV2F3NFkbmEx8XCvREpi3vDPnMDTz79xS/AxESrSmvabtiB9DTyIlq 94mk5XXYgkXMFP6SMl8PyvBih1/TWqAHrTx0DycWHiMjAVPR1hSiboW9jfaFVpvttXfq 0An2rxf1inzzlBp3fplSFwD2LKubkGzdU6w3hh/DK8wyyk1mWBTMmJwthZPJWAXKR05s fcLBLN8B4NTZfRg+8RIzmVYPhzZlvw7WyF01j6JkM3EToHnAa108OApYbjf2FF9DhZgh iH87kwwVkqznErkQue6eXZeNGy6qDOakY/UaXAwWbN/uSvFkE5UaY9GwgGI6p3O1H44S AF3g== X-Gm-Message-State: AKS2vOzjEo6ymP3D9SdttkRpP+F63lnVqgN+hKSzU8L5vlVRMPeeAxpU LsfbhrAHYIZSpFtSut4kmDmXoSfidVCm X-Received: by 10.55.7.8 with SMTP id 8mr26878497qkh.124.1498855754998; Fri, 30 Jun 2017 13:49:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Fri, 30 Jun 2017 13:48:54 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Fri, 30 Jun 2017 13:48:54 -0700 Message-ID: To: Mike Jones Cc: "id-event@ietf.org" Content-Type: multipart/alternative; boundary="001a114c46f4d96a590553338c88" Archived-At: Subject: Re: [Id-event] Security Event Token (SET) specification preventing token confusion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 20:49:18 -0000 --001a114c46f4d96a590553338c88 Content-Type: text/plain; charset="UTF-8" Thank you Mike. It's good to see the SET - ID Token issue resolved, and the other positive changes. It would be good to publish SET soon, so the working groups that will be profiling it can get going. With that in mind, should we initiate the WGLC? On Fri, Jun 30, 2017 at 1:40 PM, Mike Jones wrote: > A new version of the Security Event Token (SET) specification has been > published containing measures that prevent any possibility of confusion > between ID Tokens and SETs. Preventing confusion between SETs, access > tokens, and other kinds of JWTs is also covered. Changes were: > > - Added the Requirements for SET Profiles section. > - Expanded the Security Considerations section to describe how to > prevent confusion of SETs with ID Tokens, access tokens, and other kinds of > JWTs. > - Registered the application/secevent+jwt media type and defined how > to use it for explicit typing of SETs. > - Clarified the misleading statement that used to say that a SET > conveys a single security event. > - Added a note explicitly acknowledging that some SET profiles may > choose to convey event subject information in the event payload. > - Corrected an encoded claims set example. > - Applied grammar corrections. > > > > This draft is intended to provide solutions to the issues that had been > discussed in IETF 98 in Chicago and subsequently on the working group > mailing list. Thanks for all the great discussions that informed this > draft! > > > > The specification is available at: > > - https://tools.ietf.org/html/draft-ietf-secevent-token-02 > > > > An HTML-formatted version is also available at: > > - http://self-issued.info/docs/draft-ietf-secevent-token-02.html > > > > -- Mike > > > > P.S. This announcement was also posted at http://self-issued.info/?p=1709 > and as @selfissued . > --001a114c46f4d96a590553338c88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Mike. It's good to see the SET - ID Token is= sue resolved, and the other positive changes.

It would b= e good to publish SET soon, so the working groups that will be profiling it= can get going. With that in mind, should we initiate the WGLC?
=

On Fri, Jun 30, 2= 017 at 1:40 PM, Mike Jones <Michael.Jones@microsoft.com><= /span> wrote:

A new version of the Security Event Token (SET) spec= ification has been published containing measures that prevent any possibili= ty of confusion between ID Tokens and SETs.=C2=A0 Preventing confusion betw= een SETs, access tokens, and other kinds of JWTs is also covered.=C2=A0 Changes were:

  • Added the Requirements for SET Profiles section.
  • = Expanded the Security Considerations section to describe how to prevent con= fusion of SETs with ID Tokens, access tokens, and other kinds of JWTs.
  • Registered the application/secevent+jw= t media type and defined how to use it for explicit typing of SETs.<= u>
  • Clarified the misleading statement that used to say t= hat a SET conveys a single security event.
  • Added a no= te explicitly acknowledging that some SET profiles may choose to convey eve= nt subject information in the event payload.
  • Correcte= d an encoded claims set example.
  • Applied grammar corr= ections.

=C2=A0

This draft is intended to provide solutions to the i= ssues that had been discussed in IETF 98 in Chicago and subsequently on the= working group mailing list.=C2=A0 Thanks for all the great discussions tha= t informed this draft!

=C2=A0

The specification is available at:

=C2=A0

An HTML-formatted version is also available at:

=C2=A0

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

=C2=A0

P.S.=C2=A0 This announcement was also posted at http://self-issued.info/?p=3D1709 and as @selfissued.


--001a114c46f4d96a590553338c88-- From nobody Fri Jun 30 14:05:36 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2485A129B66 for ; Fri, 30 Jun 2017 14:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpTj6Y6htEA3 for ; Fri, 30 Jun 2017 14:05:32 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282D512741D for ; Fri, 30 Jun 2017 14:05:32 -0700 (PDT) X-AuditID: 12074424-1f7ff70000007abb-d9-5956bd195a55 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id C5.40.31419.A1DB6595; Fri, 30 Jun 2017 17:05:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v5UL5S1G018901; Fri, 30 Jun 2017 17:05:29 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5UL5Q1D002489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 17:05:27 -0400 From: Justin Richer Message-Id: <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_567935BA-B9E5-4392-BE49-F6363BCD0FDC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 17:05:25 -0400 In-Reply-To: Cc: William Denniss , Phil Hunt , Nat Sakimura , "id-event@ietf.org" , Dick Hardt To: Mike Jones References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsUixG6nriu1NyzS4NgySYvHM4ssOhZ0M1ns nfaJxWLB/EZ2izO3VjBabJrTzO7A5rFz1l12jwWbSj2WLPnJ5NG64y+7x8ent1gCWKO4bFJS czLLUov07RK4Mj4/XMVYsO4Bc0XvyVMsDYwnVjB3MXJySAiYSFy/N50RxBYSWMwksfeFSRcj F5C9kVHi+71fLBDOQyaJht3NTCBVbAKqEtPXtIDZvAJWEvc6ToJ1MwskSXxZdA2ogQMori/R +xwsLCxgLvF04hw2EJsFqPXNo99gizkFYiUunfjPBDKfWeAqo8TmjRtYQBIiAjoSjy9+Y4NY /IhV4vet84wQp8pK3Jp9iXkCI/8sJPtmIeyDCGtLLFv4mhnC1pTY372cBVNcQ6Lz20TWBYxs qxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RSU0o3MYLjw0VlB2N3j/chRgEORiUe3g0h YZFCrIllxZW5hxglOZiURHlXXguNFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCy7YLqJw3JbGy KrUoHyYlzcGiJM4rrtEYISSQnliSmp2aWpBaBJOV4eBQkuBN2w3UKFiUmp5akZaZU4KQZuLg BBnOAzT89AKQ4cUFibnFmekQ+VOMxhybZvz8xsTxasL/b0xCLHn5ealS4ry2IOMEQEozSvPg poFSXMLbw6avGMWBnhPm9QGp4gGmR7h5r4BWMQGtEp4RArKqJBEhJdXAaLhrmf0aiU0q2Q9m MJuX+7t1dW1/tZh/WlQe3/O0+cn8+0/uiPGLK/fU3fPh67I5WxPM8hPkzI8UdXB9c181zyFJ OdtqU2fEWXmzk9cmRJ2fEFrDdr9VUOTIafE9Wy7GbTDT2BGVEO8wVWKdj98Ma76Kif9nyqyX 2Ha2+Z3Ru4PPtvOzXF/3RImlOCPRUIu5qDgRANBDS9FMAwAA Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:05:35 -0000 --Apple-Mail=_567935BA-B9E5-4392-BE49-F6363BCD0FDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Unless there=E2=80=99s an encoding for security events other than JWT, = wouldn=E2=80=99t application/secevent suffice? =E2=80=94 Justin > On Jun 30, 2017, at 12:56 PM, Mike Jones = wrote: >=20 > There had already been discussions, both in Chicago, and in the JWT = BCP context, that if we were going to use a type identifier, we would = use the existing =E2=80=9Ctyp=E2=80=9D header parameter and not create a = new claim. This is a MIME type, with the ability to omit = =E2=80=9Capplication/=E2=80=9D for space reasons, if desired. > =20 > Since there appears to be broad interest in having the ability to use = explicit typing of the SET, I will plan to define the = =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the SET draft = before publishing. SETs could then include the = =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2=80=9D header parameter = value to provide explicit typing. Unless I hear objections soon, I will = proceed on this basis. > =20 > -- Mike > =C2=A0 <> > From: William Denniss [mailto:wdenniss@google.com]=20 > Sent: Friday, June 30, 2017 9:33 AM > To: Phil Hunt (IDM) > Cc: Nat Sakimura ; Dick Hardt = ; Mike Jones ; = id-event@ietf.org > Subject: Re: [Id-event] Heads-up about SET spec updates > =20 > +1 to typ. > =20 > So "typ": "set" or "typ": "event"? > =20 > On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) > wrote: > +1 to typ claim.=20 >=20 > Phil >=20 > On Jun 29, 2017, at 5:01 PM, Nat Sakimura > wrote: >=20 > Sorry for a tardy reply, but +1 for the both changes. 'exp' claim = requirement is a good practical step with a backward compatibility.=20 > Having said that, I believe inferring message types from the = existence/absence of a claim is not a good security practice. I would = like to see an explicit typing through "typ" claim added as well.=20 > =20 > Nat > =20 > On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) > wrote: > Ok.=20 > =20 > I spoke with Mike and he will post his changes to SET in a new = revision over the weekend.=20 > =20 > Phil >=20 > On Jun 29, 2017, at 1:51 PM, Dick Hardt > wrote: >=20 > I understand it is new and that there is contention.=20 > =20 > We clearly want consensus for us to be done with the draft. I think = having it in the next draft anchors the discussion so we can discuss and = arrive at consensus or an alternative.=20 > =20 > So yes, is like a new draft posted so we can discuss.=20 > =20 > On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt > wrote: > Dick, > =20 > The section is a brand new section. It seems to me that has not been = any (or limited) discussion to warrant putting it in the document. It = certainly came to me as a surprise. > =20 > I think the issue of trust model needs to be discussed. It may not = belong here at all. > =20 > Please advise. Do you want it posted in spite of consensus? > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com = > phil.hunt@oracle.com > =20 > On Jun 29, 2017, at 12:25 PM, Dick Hardt > wrote: > =20 > Hi Phil > =20 > wrt asking for more discussion, I appreciate you making the suggestion = on behalf of the chairs. It does seem there is a reasonable amount of = discussion going on now would you not agree? > =20 > I'd like to get the doc updated in time for Prague so that we have a = clear reference point for discussion there and then. > =20 > Unclear why you would post a change when it was Mike that did this = work. Am I missing something? > =20 > Mike: would you update the doc with what you think is rough consensus = when you have time so that we can have a crisp discussion in Prague? > =20 > =20 > =20 > On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) > wrote: > I agree on the exp part.=20 > =20 > Regarding the second part. I would like to see more discussion.=20 > =20 > For example, in the the use cases, there may be compatibility issues = if different set profiles cannot be sent over the same stream.=20 > =20 > Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred. = Also key management might be better tied up in how the streams are = manages because the network relationship may define the requirements = rather than the data.=20 > =20 > My initial reaction is, the profiles should stick to the data and = valid interpretation.=20 >=20 > If the group agrees I will merge the exp and post over the weekend.=20 > =20 > I can merge the second part if there is a strong agreement to do so.=20= > =20 > Thanks! >=20 > Phil >=20 > On Jun 28, 2017, at 5:24 PM, William Denniss > wrote: >=20 > Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. > =20 > By making the "exp" claim that is already = NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to do > =20 > The benefit the community will gain from the SET standard overall is a = standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. > =20 > =20 > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: > Hi folks, > =20 > I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. > =20 > The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. > =20 > The second adds the following new section: > =20 > Requirements for SET Profiles > =20 > Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. > =20 > Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. > =20 > Profile Specifications MUST clearly specify the steps that a recipient = of a SET utilizing that profile MUST perform to validate that the SET is = both syntactically and semantically valid. > =20 > It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. > =20 > I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. > =20 > Best = wishes, > -- = Mike > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 > =20 > --=20 > Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZt= YUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBN= GE&e=3D = > =20 > --=20 > Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > --=20 > Nat Sakimura >=20 > Chairman of the Board, OpenID Foundation >=20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_567935BA-B9E5-4392-BE49-F6363BCD0FDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Unless there=E2=80=99s an encoding for security events other = than JWT, wouldn=E2=80=99t application/secevent suffice?

 =E2=80=94 = Justin

On Jun 30, 2017, at 12:56 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

There had = already been discussions, both in Chicago, and in the JWT BCP context, = that if we were going to use a type identifier, we would use the = existing =E2=80=9Ctyp=E2=80=9D header parameter and not create a new = claim.  This is a MIME type, with the ability to omit = =E2=80=9Capplication/=E2=80=9D for space reasons, if desired.
 
Since there = appears to be broad interest in having the ability to use explicit = typing of the SET, I will plan to define the = =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the SET draft = before publishing.  SETs could then include the = =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2=80=9D header parameter = value to provide explicit typing.  Unless I hear objections soon, I = will proceed on this basis.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: William Denniss [mailto:wdenniss@google.com] 
Sent: Friday, June 30, 2017 9:33 = AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Nat = Sakimura <sakimura@gmail.com>; Dick Hardt <dick.hardt@gmail.com>; Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Heads-up = about SET spec updates
 
+1 to typ.
 
So "typ": "set" or "typ": "event"?
 
On Thu, Jun 29, 2017 at 5:17 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1 to typ claim. 

Phil


On = Jun 29, 2017, at 5:01 PM, Nat Sakimura <sakimura@gmail.com>= wrote:

Sorry for a tardy reply, but +1 = for the both changes. 'exp' claim requirement is a good practical step = with a backward compatibility. 
Having said that, I = believe inferring message types from the existence/absence of a claim is = not a good security practice. I would like to see an explicit typing = through "typ" claim added as well. 
 
Nat
 
On Fri, Jun 30, 2017 at = 7:04 AM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Ok. 
 
I spoke = with Mike and he will post his changes to SET in a new revision over the = weekend. 
 
Phil


On Jun 29, 2017, at = 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I understand it is new and = that there is contention. 
 
We clearly want consensus for us to be done with the draft. I = think having it in the next draft anchors the discussion so we can = discuss and arrive at consensus or an alternative. 
 
So yes, is like a new draft posted so = we can discuss. 
 
On Thu, = Jun 29, 2017 at 12:58 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Dick,
 
The section is a brand new section. It seems to me that has = not been any (or limited) discussion to warrant putting it in the = document.  It certainly came to me as a surprise.
 
I think the issue of trust model needs = to be discussed.  It may not belong here at all.
 
Please advise.  Do you want it = posted in spite of consensus?
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect & = Standards
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Jun 29, 2017, at 12:25 = PM, Dick Hardt <dick.hardt@gmail.com> wrote:
 
Hi = Phil
 
wrt asking for more discussion, I = appreciate you making the suggestion on behalf of the chairs. It does = seem there is a reasonable amount of discussion going on now would you = not agree?
 
I'd like to get the doc updated in time for Prague so that we = have a clear reference point for discussion there and then.
 
Unclear why you would post = a change when it was Mike that did this work. Am I missing = something?
 
Mike: would you update the doc with what you think is rough = consensus when you have time so that we can have a crisp discussion in = Prague?
 
 
 
On Wed, Jun 28, 2017 at = 5:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I= agree on the exp part. 
 
Regarding the second part. I would like = to see more discussion. 
 
For example, in the the use cases, = there may be compatibility issues if different set profiles cannot be = sent over the same stream. 
 
Such profiles should avoid things like = requiring signing and encryption without consideration regarding how = they are transferred.  Also key management might be better tied up = in how the streams are manages because the network relationship may = define the requirements rather than the data. 
 
My initial reaction is, the profiles = should stick to the data and valid interpretation. 
If the group agrees I will merge the exp and post over the = weekend. 
 
I can merge the second part if there is = a strong agreement to do so. 
 
Thanks!

Phil


On = Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you Mike for working = on this. I'm very happy with the change regarding the "exp" claim, and = believe it is the best resolution to the "ID Token" confusion = concern.
 
By making the "exp" claim that is already NOT RECOMMENDED in the = current draft a MUST NOT, we can provide the ID Tokens and SET = uniqueness guarantee that is desired, allowing these two types of JWTs = to be used with a common issuer. This also allows "sub" to be used for = its intended purpose (as defined by RFC7519) without modification, which = other working groups that wish to profile SET have expressed an interest = to do
 
The benefit the community will gain from the SET standard = overall is a standard way to express events that won't conflict with ID = Token (no "iss" partitioning required). With Mike's changes we achieve = that, and in a way that retains the original simplicity, extensibility = and generalizability goals of SET by not redefining any of JWT's = standard claims.
 
 
On Wed, Jun 28, 2017 at = 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Hi folks,
 
I wanted to give you a heads-up about two SET spec updates in = the current editor=E2=80=99s draft before they are published.
 
The first = solves the potential ID Token / SET confusion problem by requiring that = SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens = could also be generated by the same issuer.  Because =E2=80=9Cexp=E2=80= =9D is a required ID Token claim, SETs would therefore be rejected by = existing ID Token validation code.  Note that this solution is = already recommended in the specification.  The editor=E2=80=99s = draft update makes this solution mandatory.  This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since.
 
The = second adds the following new section:
 
Requirements for SET = Profiles
 
Profile Specifications for SETs define the syntax and = semantics of SETs conforming to that SET profile and rules for = validating those SETs. The syntax defined by profiling specifications = includes what claims and event payload values are used by SETs utilizing = the profile.
 
Defining the semantics of the SET contents for SETs utilizing = the profile is equally important. Possibly most important is defining = the procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses = the iss claim value as its = input.
 
Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid.
 
It=E2=80=99= s included to inform profile writers about what they must do to be able = to use SETs securely.  While much of the discussion as of late has = been about syntax, semantics is equally important, and must be = considered by profile writers and deployers.
 
I believe = that the new section contains only statements that are already factually = accurate requirements but that were previously unstated.  The = editor=E2=80=99s draft makes these requirements explicit.  Feedback = on how to make these requirements even more clear, is of course, = welcomed.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjU= eXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D
 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
-- 

Nat = Sakimura

Chairman of the Board, = OpenID Foundation

 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=
= --Apple-Mail=_567935BA-B9E5-4392-BE49-F6363BCD0FDC-- From nobody Fri Jun 30 14:07:50 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E85129B8C for ; Fri, 30 Jun 2017 14:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKCoXVqRTRLx for ; Fri, 30 Jun 2017 14:07:44 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0133.outbound.protection.outlook.com [104.47.38.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD20127137 for ; Fri, 30 Jun 2017 14:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6Lf6GV69pDz5uAYDXYB6Vv+GzOjwap0GEJYaCA0Oei0=; b=cCKsVBp01lkcmV6E9uSxMYUneIysSWEoTSeNOY4aUgYbs8QE0UhJeHeXYOqC6PZ/MU0RmOAnwzH1V+aRw4NptbvBqEV+yuLBP6S/UVlMZTxczLCtEYGAsgZ6bySiOE9ODEA2j0a/A3vtIcIDMkiLliDiHv5h63EJGXRcviiyJsE= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0168.namprd21.prod.outlook.com (10.173.192.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.1; Fri, 30 Jun 2017 21:07:41 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 21:07:41 +0000 From: Mike Jones To: Justin Richer CC: William Denniss , Phil Hunt , Nat Sakimura , "id-event@ietf.org" , Dick Hardt Thread-Topic: [Id-event] Heads-up about SET spec updates Thread-Index: AdLwa3VhxmOh1ap9Sxqj4ofmRP4gvAAApZIAAACBMYAAJ1aBgAABJWgAAAHadAAAApHigAAEEu8AAACVdYAAIhDoAAAAmlLgAAjl/4AAAAaaQA== Date: Fri, 30 Jun 2017 21:07:41 +0000 Message-ID: References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> In-Reply-To: <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-30T14:07:40.2021599-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0168; 7:Xveb3PQ2QMsXDraza1oQ9mYbqRqr166yHPjK/Gjrpa5MhZHqgk6jxVYA0bV8gtaTpExy5Feb8Ip1SieI/U+VNZyKDPj2VUUj93eKrHy1jrOYq0oGvXN/lT2j+Oj3HCvvUQTIsFa+5ipRgd1jZuM7N2bYIrK/0emrOJIq+obZGXCAMC3YUe2BayK3Ky109oR/tgNETRieQ4KdaJUZt4znBaOEBFlu8lnLQOZXwdpvtKSr9C3qqhDZjlsWEbZpQQ7KZIrWklqLRwGMs9pIwuLrtjWwjrJYDuyC6UGXUo7LEYYUnw4K4tk4WLen3g/DWAM1zd9aq2IkZ0b4ypJ04mg+ujLA/3vKuZE369Y7yeelXQvPpGjp9RedhEMp9VPqRtD0T4IGryZT/UVfA68qrH+UZmtvT611z5XI0ZqABWXmRW9LLvpHEFa6xSdxKdZtACDhDPYFb7ie5ciSr7Q/DsiJ9T8rsJCHHc5YbkPh2vvTWwhNYQXp94wHpL7QTgO6tYRbjPcCF15Q0EVD6g4zt3AfDIXoHV3BvjZy10WLkf8YyJq3Cfg7IgWzvylxCwgETmmlh0JKi+NNweyoHj/sbNES/WWd8+jBIMtyYAfIkH7kgdTkmimyPjKPd/WO+jpUo+QzKno3MpzDBAxE9WbDbDYFq6zOsxLPmWfOj82v9zfhfjCjSLti5Xb8xIHrfq9zQNyB7uSBWHwds2hW/KHAs73OQFYLxsD/TYFy/1SNtJOHNDjDdYhkRm3DWqLNDMYD2w9qVNIXU2mNNikMX981xAcfVtmCOxRfKPJN2c3CvDF9DQ2hpqFuN8q68RE4KxicuDgx x-ms-office365-filtering-correlation-id: efae6147-c6bb-4ba5-648e-08d4bffc0bf6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0168; x-ms-traffictypediagnostic: CY4PR21MB0168: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(10436049006162)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(211936372134217)(100405760836317)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910020)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0168; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0168; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39860400002)(39410400002)(39840400002)(39450400003)(78124002)(377454003)(24454002)(76104003)(3660700001)(2171002)(86362001)(53936002)(14454004)(53546010)(53946003)(229853002)(3280700002)(10290500003)(6116002)(2950100002)(102836003)(790700001)(77096006)(8676002)(54896002)(19609705001)(50986999)(81166006)(74316002)(7696004)(2900100001)(7736002)(4326008)(606006)(54356999)(575784001)(6436002)(72206003)(9686003)(2420400007)(110136004)(10090500001)(86612001)(25786009)(15650500001)(6246003)(33656002)(76176999)(7110500001)(99286003)(2906002)(6306002)(38730400002)(478600001)(6916009)(55016002)(39060400002)(54906002)(189998001)(8936002)(5005710100001)(8990500004)(93886004)(6506006)(5660300001)(966005)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0168; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05049620FF96A3327DEC735DF5D30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 21:07:41.7231 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0168 Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:07:48 -0000 --_000_CY4PR21MB05049620FF96A3327DEC735DF5D30CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgbWF5IGJlIGEgU0FNTCBlbmNvZGluZyBpbiB0aGUgd29ya3MuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdC5lZHVdDQpTZW50 OiBGcmlkYXksIEp1bmUgMzAsIDIwMTcgMjowNSBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2ds ZS5jb20+OyBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPjsgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb20+OyBpZC1ldmVudEBpZXRmLm9yZzsgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBIZWFkcy11cCBhYm91dCBT RVQgc3BlYyB1cGRhdGVzDQoNClVubGVzcyB0aGVyZeKAmXMgYW4gZW5jb2RpbmcgZm9yIHNlY3Vy aXR5IGV2ZW50cyBvdGhlciB0aGFuIEpXVCwgd291bGRu4oCZdCBhcHBsaWNhdGlvbi9zZWNldmVu dCBzdWZmaWNlPw0KDQog4oCUIEp1c3Rpbg0KDQpPbiBKdW4gMzAsIDIwMTcsIGF0IDEyOjU2IFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGVyZSBoYWQgYWxyZWFkeSBiZWVuIGRp c2N1c3Npb25zLCBib3RoIGluIENoaWNhZ28sIGFuZCBpbiB0aGUgSldUIEJDUCBjb250ZXh0LCB0 aGF0IGlmIHdlIHdlcmUgZ29pbmcgdG8gdXNlIGEgdHlwZSBpZGVudGlmaWVyLCB3ZSB3b3VsZCB1 c2UgdGhlIGV4aXN0aW5nIOKAnHR5cOKAnSBoZWFkZXIgcGFyYW1ldGVyIGFuZCBub3QgY3JlYXRl IGEgbmV3IGNsYWltLiAgVGhpcyBpcyBhIE1JTUUgdHlwZSwgd2l0aCB0aGUgYWJpbGl0eSB0byBv bWl0IOKAnGFwcGxpY2F0aW9uL+KAnSBmb3Igc3BhY2UgcmVhc29ucywgaWYgZGVzaXJlZC4NCg0K U2luY2UgdGhlcmUgYXBwZWFycyB0byBiZSBicm9hZCBpbnRlcmVzdCBpbiBoYXZpbmcgdGhlIGFi aWxpdHkgdG8gdXNlIGV4cGxpY2l0IHR5cGluZyBvZiB0aGUgU0VULCBJIHdpbGwgcGxhbiB0byBk ZWZpbmUgdGhlIOKAnGFwcGxpY2F0aW9uL3NlY2V2ZW50K2p3dOKAnSBNSU1FIHR5cGUgaW4gdGhl IFNFVCBkcmFmdCBiZWZvcmUgcHVibGlzaGluZy4gIFNFVHMgY291bGQgdGhlbiBpbmNsdWRlIHRo ZSDigJx0eXDigJ064oCcc2VjZXZlbnQrand04oCdIGhlYWRlciBwYXJhbWV0ZXIgdmFsdWUgdG8g cHJvdmlkZSBleHBsaWNpdCB0eXBpbmcuICBVbmxlc3MgSSBoZWFyIG9iamVjdGlvbnMgc29vbiwg SSB3aWxsIHByb2NlZWQgb24gdGhpcyBiYXNpcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogV2lsbGlhbSBE ZW5uaXNzIFttYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVuZSAz MCwgMjAxNyA5OjMzIEFNDQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KQ2M6IE5hdCBTYWtpbXVyYSA8c2FraW11 cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PjsgRGljayBIYXJkdCA8ZGlj ay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj47IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj47IGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIEhlYWRzLXVwIGFib3V0IFNFVCBzcGVjIHVwZGF0ZXMN Cg0KKzEgdG8gdHlwLg0KDQpTbyAidHlwIjogInNldCIgb3IgInR5cCI6ICJldmVudCI/DQoNCk9u IFRodSwgSnVuIDI5LCAyMDE3IGF0IDU6MTcgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQorMSB0byB0 eXAgY2xhaW0uDQoNClBoaWwNCg0KT24gSnVuIDI5LCAyMDE3LCBhdCA1OjAxIFBNLCBOYXQgU2Fr aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3Jv dGU6DQpTb3JyeSBmb3IgYSB0YXJkeSByZXBseSwgYnV0ICsxIGZvciB0aGUgYm90aCBjaGFuZ2Vz LiAnZXhwJyBjbGFpbSByZXF1aXJlbWVudCBpcyBhIGdvb2QgcHJhY3RpY2FsIHN0ZXAgd2l0aCBh IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuDQpIYXZpbmcgc2FpZCB0aGF0LCBJIGJlbGlldmUgaW5m ZXJyaW5nIG1lc3NhZ2UgdHlwZXMgZnJvbSB0aGUgZXhpc3RlbmNlL2Fic2VuY2Ugb2YgYSBjbGFp bSBpcyBub3QgYSBnb29kIHNlY3VyaXR5IHByYWN0aWNlLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGFu IGV4cGxpY2l0IHR5cGluZyB0aHJvdWdoICJ0eXAiIGNsYWltIGFkZGVkIGFzIHdlbGwuDQoNCk5h dA0KDQpPbiBGcmksIEp1biAzMCwgMjAxNyBhdCA3OjA0IEFNIFBoaWwgSHVudCAoSURNKSA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpP ay4NCg0KSSBzcG9rZSB3aXRoIE1pa2UgYW5kIGhlIHdpbGwgcG9zdCBoaXMgY2hhbmdlcyB0byBT RVQgaW4gYSBuZXcgcmV2aXNpb24gb3ZlciB0aGUgd2Vla2VuZC4NCg0KUGhpbA0KDQpPbiBKdW4g MjksIDIwMTcsIGF0IDE6NTEgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KSSB1bmRlcnN0YW5kIGl0IGlzIG5l dyBhbmQgdGhhdCB0aGVyZSBpcyBjb250ZW50aW9uLg0KDQpXZSBjbGVhcmx5IHdhbnQgY29uc2Vu c3VzIGZvciB1cyB0byBiZSBkb25lIHdpdGggdGhlIGRyYWZ0LiBJIHRoaW5rIGhhdmluZyBpdCBp biB0aGUgbmV4dCBkcmFmdCBhbmNob3JzIHRoZSBkaXNjdXNzaW9uIHNvIHdlIGNhbiBkaXNjdXNz IGFuZCBhcnJpdmUgYXQgY29uc2Vuc3VzIG9yIGFuIGFsdGVybmF0aXZlLg0KDQpTbyB5ZXMsIGlz IGxpa2UgYSBuZXcgZHJhZnQgcG9zdGVkIHNvIHdlIGNhbiBkaXNjdXNzLg0KDQpPbiBUaHUsIEp1 biAyOSwgMjAxNyBhdCAxMjo1OCBQTSBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KRGljaywNCg0KVGhlIHNlY3Rpb24g aXMgYSBicmFuZCBuZXcgc2VjdGlvbi4gSXQgc2VlbXMgdG8gbWUgdGhhdCBoYXMgbm90IGJlZW4g YW55IChvciBsaW1pdGVkKSBkaXNjdXNzaW9uIHRvIHdhcnJhbnQgcHV0dGluZyBpdCBpbiB0aGUg ZG9jdW1lbnQuICBJdCBjZXJ0YWlubHkgY2FtZSB0byBtZSBhcyBhIHN1cnByaXNlLg0KDQpJIHRo aW5rIHRoZSBpc3N1ZSBvZiB0cnVzdCBtb2RlbCBuZWVkcyB0byBiZSBkaXNjdXNzZWQuICBJdCBt YXkgbm90IGJlbG9uZyBoZXJlIGF0IGFsbC4NCg0KUGxlYXNlIGFkdmlzZS4gIERvIHlvdSB3YW50 IGl0IHBvc3RlZCBpbiBzcGl0ZSBvZiBjb25zZW5zdXM/DQoNClBoaWwNCg0KT3JhY2xlIENvcnBv cmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QgJiBTdGFuZGFyZHMNCkBp bmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3 TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09RHpodl8xYVRBaHpzeVFx MVVwQ083cWlXeHpBSEpYOHktX1ZHSkMzRUFDZyZzPWZFVnZGc0Vxa1RtQ3BZNnNJYV9HVl9TM0d5 MWd4aEc1NldhYncyNEcwTEEmZT0+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQoNCk9uIEp1biAyOSwgMjAxNywgYXQgMTI6MjUgUE0sIERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdy b3RlOg0KDQpIaSBQaGlsDQoNCndydCBhc2tpbmcgZm9yIG1vcmUgZGlzY3Vzc2lvbiwgSSBhcHBy ZWNpYXRlIHlvdSBtYWtpbmcgdGhlIHN1Z2dlc3Rpb24gb24gYmVoYWxmIG9mIHRoZSBjaGFpcnMu IEl0IGRvZXMgc2VlbSB0aGVyZSBpcyBhIHJlYXNvbmFibGUgYW1vdW50IG9mIGRpc2N1c3Npb24g Z29pbmcgb24gbm93IHdvdWxkIHlvdSBub3QgYWdyZWU/DQoNCkknZCBsaWtlIHRvIGdldCB0aGUg ZG9jIHVwZGF0ZWQgaW4gdGltZSBmb3IgUHJhZ3VlIHNvIHRoYXQgd2UgaGF2ZSBhIGNsZWFyIHJl ZmVyZW5jZSBwb2ludCBmb3IgZGlzY3Vzc2lvbiB0aGVyZSBhbmQgdGhlbi4NCg0KVW5jbGVhciB3 aHkgeW91IHdvdWxkIHBvc3QgYSBjaGFuZ2Ugd2hlbiBpdCB3YXMgTWlrZSB0aGF0IGRpZCB0aGlz IHdvcmsuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCk1pa2U6IHdvdWxkIHlvdSB1cGRhdGUg dGhlIGRvYyB3aXRoIHdoYXQgeW91IHRoaW5rIGlzIHJvdWdoIGNvbnNlbnN1cyB3aGVuIHlvdSBo YXZlIHRpbWUgc28gdGhhdCB3ZSBjYW4gaGF2ZSBhIGNyaXNwIGRpc2N1c3Npb24gaW4gUHJhZ3Vl Pw0KDQoNCg0KT24gV2VkLCBKdW4gMjgsIDIwMTcgYXQgNTozOCBQTSwgUGhpbCBIdW50IChJRE0p IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90 ZToNCkkgYWdyZWUgb24gdGhlIGV4cCBwYXJ0Lg0KDQpSZWdhcmRpbmcgdGhlIHNlY29uZCBwYXJ0 LiBJIHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgZGlzY3Vzc2lvbi4NCg0KRm9yIGV4YW1wbGUsIGlu IHRoZSB0aGUgdXNlIGNhc2VzLCB0aGVyZSBtYXkgYmUgY29tcGF0aWJpbGl0eSBpc3N1ZXMgaWYg ZGlmZmVyZW50IHNldCBwcm9maWxlcyBjYW5ub3QgYmUgc2VudCBvdmVyIHRoZSBzYW1lIHN0cmVh bS4NCg0KU3VjaCBwcm9maWxlcyBzaG91bGQgYXZvaWQgdGhpbmdzIGxpa2UgcmVxdWlyaW5nIHNp Z25pbmcgYW5kIGVuY3J5cHRpb24gd2l0aG91dCBjb25zaWRlcmF0aW9uIHJlZ2FyZGluZyBob3cg dGhleSBhcmUgdHJhbnNmZXJyZWQuICBBbHNvIGtleSBtYW5hZ2VtZW50IG1pZ2h0IGJlIGJldHRl ciB0aWVkIHVwIGluIGhvdyB0aGUgc3RyZWFtcyBhcmUgbWFuYWdlcyBiZWNhdXNlIHRoZSBuZXR3 b3JrIHJlbGF0aW9uc2hpcCBtYXkgZGVmaW5lIHRoZSByZXF1aXJlbWVudHMgcmF0aGVyIHRoYW4g dGhlIGRhdGEuDQoNCk15IGluaXRpYWwgcmVhY3Rpb24gaXMsIHRoZSBwcm9maWxlcyBzaG91bGQg c3RpY2sgdG8gdGhlIGRhdGEgYW5kIHZhbGlkIGludGVycHJldGF0aW9uLg0KDQpJZiB0aGUgZ3Jv dXAgYWdyZWVzIEkgd2lsbCBtZXJnZSB0aGUgZXhwIGFuZCBwb3N0IG92ZXIgdGhlIHdlZWtlbmQu DQoNCkkgY2FuIG1lcmdlIHRoZSBzZWNvbmQgcGFydCBpZiB0aGVyZSBpcyBhIHN0cm9uZyBhZ3Jl ZW1lbnQgdG8gZG8gc28uDQoNClRoYW5rcyENCg0KUGhpbA0KDQpPbiBKdW4gMjgsIDIwMTcsIGF0 IDU6MjQgUE0sIFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xlLmNvbTxtYWlsdG86d2Rl bm5pc3NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IE1pa2UgZm9yIHdvcmtpbmcgb24g dGhpcy4gSSdtIHZlcnkgaGFwcHkgd2l0aCB0aGUgY2hhbmdlIHJlZ2FyZGluZyB0aGUgImV4cCIg Y2xhaW0sIGFuZCBiZWxpZXZlIGl0IGlzIHRoZSBiZXN0IHJlc29sdXRpb24gdG8gdGhlICJJRCBU b2tlbiIgY29uZnVzaW9uIGNvbmNlcm4uDQoNCkJ5IG1ha2luZyB0aGUgImV4cCIgY2xhaW0gdGhh dCBpcyBhbHJlYWR5PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRHRv a2VuLTJEMDEtMjNzZWN0aW9uLTJEMi4xJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smbT1fWEY5OTR6Vm4xX0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgw JnM9NUw5cXFIX2V2a2xYLUhqREY4S2taMmU1Yk5hNmZaYzNrSklYTDJxZlVXcyZlPT4gTk9UIFJF Q09NTUVOREVEIGluIHRoZSBjdXJyZW50IGRyYWZ0IGEgTVVTVCBOT1QsIHdlIGNhbiBwcm92aWRl IHRoZSBJRCBUb2tlbnMgYW5kIFNFVCB1bmlxdWVuZXNzIGd1YXJhbnRlZSB0aGF0IGlzIGRlc2ly ZWQsIGFsbG93aW5nIHRoZXNlIHR3byB0eXBlcyBvZiBKV1RzIHRvIGJlIHVzZWQgd2l0aCBhIGNv bW1vbiBpc3N1ZXIuIFRoaXMgYWxzbyBhbGxvd3MgInN1YiIgdG8gYmUgdXNlZCBmb3IgaXRzIGlu dGVuZGVkIHB1cnBvc2UgKGFzIGRlZmluZWQgYnkgUkZDNzUxOSkgd2l0aG91dCBtb2RpZmljYXRp b24sIHdoaWNoIG90aGVyIHdvcmtpbmcgZ3JvdXBzIHRoYXQgd2lzaCB0byBwcm9maWxlIFNFVCBo YXZlIGV4cHJlc3NlZCBhbiBpbnRlcmVzdCB0byBkbw0KDQpUaGUgYmVuZWZpdCB0aGUgY29tbXVu aXR5IHdpbGwgZ2FpbiBmcm9tIHRoZSBTRVQgc3RhbmRhcmQgb3ZlcmFsbCBpcyBhIHN0YW5kYXJk IHdheSB0byBleHByZXNzIGV2ZW50cyB0aGF0IHdvbid0IGNvbmZsaWN0IHdpdGggSUQgVG9rZW4g KG5vICJpc3MiIHBhcnRpdGlvbmluZyByZXF1aXJlZCkuIFdpdGggTWlrZSdzIGNoYW5nZXMgd2Ug YWNoaWV2ZSB0aGF0LCBhbmQgaW4gYSB3YXkgdGhhdCByZXRhaW5zIHRoZSBvcmlnaW5hbCBzaW1w bGljaXR5LCBleHRlbnNpYmlsaXR5IGFuZCBnZW5lcmFsaXphYmlsaXR5IGdvYWxzIG9mIFNFVCBi eSBub3QgcmVkZWZpbmluZyBhbnkgb2YgSldUJ3Mgc3RhbmRhcmQgY2xhaW1zLg0KDQoNCk9uIFdl ZCwgSnVuIDI4LCAyMDE3IGF0IDU6MDggUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpI aSBmb2xrcywNCg0KSSB3YW50ZWQgdG8gZ2l2ZSB5b3UgYSBoZWFkcy11cCBhYm91dCB0d28gU0VU IHNwZWMgdXBkYXRlcyBpbiB0aGUgY3VycmVudCBlZGl0b3LigJlzIGRyYWZ0IGJlZm9yZSB0aGV5 IGFyZSBwdWJsaXNoZWQuDQoNClRoZSBmaXJzdCBzb2x2ZXMgdGhlIHBvdGVudGlhbCBJRCBUb2tl biAvIFNFVCBjb25mdXNpb24gcHJvYmxlbSBieSByZXF1aXJpbmcgdGhhdCBTRVRzIG5vdCBpbmNs dWRlIGEgdG9wLWxldmVsIOKAnGV4cOKAnSBjbGFpbSB3aGVuIElEIFRva2VucyBjb3VsZCBhbHNv IGJlIGdlbmVyYXRlZCBieSB0aGUgc2FtZSBpc3N1ZXIuICBCZWNhdXNlIOKAnGV4cOKAnSBpcyBh IHJlcXVpcmVkIElEIFRva2VuIGNsYWltLCBTRVRzIHdvdWxkIHRoZXJlZm9yZSBiZSByZWplY3Rl ZCBieSBleGlzdGluZyBJRCBUb2tlbiB2YWxpZGF0aW9uIGNvZGUuICBOb3RlIHRoYXQgdGhpcyBz b2x1dGlvbiBpcyBhbHJlYWR5IHJlY29tbWVuZGVkIGluIHRoZSBzcGVjaWZpY2F0aW9uLiAgVGhl IGVkaXRvcuKAmXMgZHJhZnQgdXBkYXRlIG1ha2VzIHRoaXMgc29sdXRpb24gbWFuZGF0b3J5LiAg VGhpcyBwcm92aWRlcyBhIHNpbXBsZSBhbmQgZHVyYWJsZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxl bSB3ZSBhZ3JlZWQgdG8gc29sdmUgYXQgSUVURiA5OCBpbiBDaGljYWdvIGFuZCB0aGF0IGhhcyBi ZWVuIHRoZSBzdWJqZWN0IG9mIG11Y2ggZGlzY3Vzc2lvbiBzaW5jZS4NCg0KVGhlIHNlY29uZCBh ZGRzIHRoZSBmb2xsb3dpbmcgbmV3IHNlY3Rpb246DQoNClJlcXVpcmVtZW50cyBmb3IgU0VUIFBy b2ZpbGVzDQoNClByb2ZpbGUgU3BlY2lmaWNhdGlvbnMgZm9yIFNFVHMgZGVmaW5lIHRoZSBzeW50 YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIGNvbmZvcm1pbmcgdG8gdGhhdCBTRVQgcHJvZmlsZSBh bmQgcnVsZXMgZm9yIHZhbGlkYXRpbmcgdGhvc2UgU0VUcy4gVGhlIHN5bnRheCBkZWZpbmVkIGJ5 IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBpbmNsdWRlcyB3aGF0IGNsYWltcyBhbmQgZXZlbnQg cGF5bG9hZCB2YWx1ZXMgYXJlIHVzZWQgYnkgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUuDQoN CkRlZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFNFVCBjb250ZW50cyBmb3IgU0VUcyB1dGls aXppbmcgdGhlIHByb2ZpbGUgaXMgZXF1YWxseSBpbXBvcnRhbnQuIFBvc3NpYmx5IG1vc3QgaW1w b3J0YW50IGlzIGRlZmluaW5nIHRoZSBwcm9jZWR1cmVzIHVzZWQgdG8gdmFsaWRhdGUgdGhlIFNF VCBpc3N1ZXIgYW5kIHRvIG9idGFpbiB0aGUga2V5cyBjb250cm9sbGVkIGJ5IHRoZSBpc3N1ZXIg dGhhdCB3ZXJlIHVzZWQgZm9yIGNyeXB0b2dyYXBoaWMgb3BlcmF0aW9ucyB1c2VkIGluIHRoZSBK V1QgcmVwcmVzZW50aW5nIHRoZSBTRVQuIEZvciBpbnN0YW5jZSwgc29tZSBwcm9maWxlcyBtYXkg ZGVmaW5lIGFuIGFsZ29yaXRobSBmb3IgcmV0cmlldmluZyB0aGUgU0VUIGlzc3VlcidzIGtleXMg dGhhdCB1c2VzIHRoZSBpc3MgY2xhaW0gdmFsdWUgYXMgaXRzIGlucHV0Lg0KDQpQcm9maWxlIFNw ZWNpZmljYXRpb25zIE1VU1QgY2xlYXJseSBzcGVjaWZ5IHRoZSBzdGVwcyB0aGF0IGEgcmVjaXBp ZW50IG9mIGEgU0VUIHV0aWxpemluZyB0aGF0IHByb2ZpbGUgTVVTVCBwZXJmb3JtIHRvIHZhbGlk YXRlIHRoYXQgdGhlIFNFVCBpcyBib3RoIHN5bnRhY3RpY2FsbHkgYW5kIHNlbWFudGljYWxseSB2 YWxpZC4NCg0KSXTigJlzIGluY2x1ZGVkIHRvIGluZm9ybSBwcm9maWxlIHdyaXRlcnMgYWJvdXQg d2hhdCB0aGV5IG11c3QgZG8gdG8gYmUgYWJsZSB0byB1c2UgU0VUcyBzZWN1cmVseS4gIFdoaWxl IG11Y2ggb2YgdGhlIGRpc2N1c3Npb24gYXMgb2YgbGF0ZSBoYXMgYmVlbiBhYm91dCBzeW50YXgs IHNlbWFudGljcyBpcyBlcXVhbGx5IGltcG9ydGFudCwgYW5kIG11c3QgYmUgY29uc2lkZXJlZCBi eSBwcm9maWxlIHdyaXRlcnMgYW5kIGRlcGxveWVycy4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIG5l dyBzZWN0aW9uIGNvbnRhaW5zIG9ubHkgc3RhdGVtZW50cyB0aGF0IGFyZSBhbHJlYWR5IGZhY3R1 YWxseSBhY2N1cmF0ZSByZXF1aXJlbWVudHMgYnV0IHRoYXQgd2VyZSBwcmV2aW91c2x5IHVuc3Rh dGVkLiAgVGhlIGVkaXRvcuKAmXMgZHJhZnQgbWFrZXMgdGhlc2UgcmVxdWlyZW1lbnRzIGV4cGxp Y2l0LiAgRmVlZGJhY2sgb24gaG93IHRvIG1ha2UgdGhlc2UgcmVxdWlyZW1lbnRzIGV2ZW4gbW9y ZSBjbGVhciwgaXMgb2YgY291cnNlLCB3ZWxjb21lZC4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPV9YRjk5NHpW bjFfQWVTLUN6U3RxT1FhVlFwc2RqanZmQnkzNVMwbzd0SDAmcz0zczFHQ2MtM2cyS1VfcE42SHZX VkhnV0JKWHM2T0dQWThLLW5GYXFVeEtRJmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGll dGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1FVGJHSXhS WkxjUWZZWnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdRJnM9bE1Tb3diRG5qVWVYRTd6THBy R0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZlPT4NCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhl IEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0 Q19sTElHayZtPUVUYkdJeFJaTGNRZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9YR1Emcz0z VWQxdjJwR1hEdzQ1ZzlGa21Jd3RXbzQ1emRGR19OU2djamNmNmtIbkV3JmU9PiBtYWlsIGxpc3Qg dG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0K SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smbT1FVGJHSXhSWkxjUWZZWnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdR JnM9bE1Tb3diRG5qVWVYRTd6THByR0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZlPQ0KDQotLQ0K U3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Eemh2XzFhVEFoenN5UXExVXBDTzdxaVd4ekFISlg4 eS1fVkdKQzNFQUNnJnM9Zks4UlhuMDFhaXhvWXNDbGtrdWRnSkdFeEgwZGR2NkN2M0tYRlk0UHRD MCZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1sRmk5eDNYemhCMU9Id2hWbm1IMmFyaWRXMS13MVRUY0hCMkht ZWtjcmpNJnM9bGQwbGk0ZHFhajZTOG11R3N4cEJjSEJjWTFQbHlMQkxKLVRjeUVycXowOCZlPT4N Ci0tDQpOYXQgU2FraW11cmENCkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRp b24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklk LWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0K DQo= --_000_CY4PR21MB05049620FF96A3327DEC735DF5D30CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5tMjA5MjcwMzgwNzA5MzA2NDUxMGhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTptMjA5MjcwMzgwNzA5MzA2NDUxMGhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+VGhlcmUgbWF5IGJlIGEgU0FNTCBlbmNvZGluZyBpbiB0aGUgd29ya3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1p dC5lZHVdIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMzAsIDIwMTcgMjowNSBQTTxi cj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gV2lsbGlhbSBEZW5uaXNzICZsdDt3ZGVubmlzc0Bnb29nbGUu Y29tJmd0OzsgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs7IE5hdCBTYWtp bXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0OzsgaWQtZXZlbnRAaWV0Zi5vcmc7IERpY2sg SGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0lkLWV2ZW50XSBIZWFkcy11cCBhYm91dCBTRVQgc3BlYyB1cGRhdGVzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vbmxlc3MgdGhlcmXigJlzIGFuIGVuY29kaW5n IGZvciBzZWN1cml0eSBldmVudHMgb3RoZXIgdGhhbiBKV1QsIHdvdWxkbuKAmXQgYXBwbGljYXRp b24vc2VjZXZlbnQgc3VmZmljZT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biAzMCwgMjAxNywgYXQgMTI6NTYgUE0sIE1p a2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i Pk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPlRoZXJlIGhhZCBhbHJlYWR5IGJlZW4gZGlzY3Vzc2lvbnMsIGJvdGggaW4gQ2hpY2Fnbywg YW5kIGluIHRoZSBKV1QgQkNQIGNvbnRleHQsIHRoYXQgaWYgd2Ugd2VyZSBnb2luZyB0byB1c2Ug YSB0eXBlIGlkZW50aWZpZXIsIHdlIHdvdWxkIHVzZSB0aGUgZXhpc3Rpbmcg4oCcdHlw4oCdIGhl YWRlciBwYXJhbWV0ZXIgYW5kIG5vdCBjcmVhdGUgYSBuZXcgY2xhaW0uJm5ic3A7IFRoaXMNCiBp cyBhIE1JTUUgdHlwZSwgd2l0aCB0aGUgYWJpbGl0eSB0byBvbWl0IOKAnGFwcGxpY2F0aW9uL+KA nSBmb3Igc3BhY2UgcmVhc29ucywgaWYgZGVzaXJlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlNpbmNlIHRoZXJlIGFw cGVhcnMgdG8gYmUgYnJvYWQgaW50ZXJlc3QgaW4gaGF2aW5nIHRoZSBhYmlsaXR5IHRvIHVzZSBl eHBsaWNpdCB0eXBpbmcgb2YgdGhlIFNFVCwgSSB3aWxsIHBsYW4gdG8gZGVmaW5lIHRoZSDigJxh cHBsaWNhdGlvbi9zZWNldmVudCYjNDM7and04oCdIE1JTUUgdHlwZSBpbiB0aGUgU0VUIGRyYWZ0 IGJlZm9yZSBwdWJsaXNoaW5nLiZuYnNwOyBTRVRzIGNvdWxkDQogdGhlbiBpbmNsdWRlIHRoZSDi gJx0eXDigJ064oCcc2VjZXZlbnQmIzQzO2p3dOKAnSBoZWFkZXIgcGFyYW1ldGVyIHZhbHVlIHRv IHByb3ZpZGUgZXhwbGljaXQgdHlwaW5nLiZuYnNwOyBVbmxlc3MgSSBoZWFyIG9iamVjdGlvbnMg c29vbiwgSSB3aWxsIHByb2NlZWQgb24gdGhpcyBiYXNpcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldpbGxpYW0gRGVu bmlzcyBbPGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iPm1haWx0bzp3ZGVubmlz c0Bnb29nbGUuY29tPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPkZyaWRheSwgSnVuZSAzMCwgMjAxNyA5OjMzIEFNPGJyPg0KPGI+ VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Q aGlsIEh1bnQgKElETSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+ cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TmF0IFNha2ltdXJhICZsdDs8YSBo cmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0 OzsgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5k aWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7OyBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+aWQtZXZlbnRA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIEhlYWRzLXVwIGFib3V0IFNF VCBzcGVjIHVwZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byB0eXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyAm cXVvdDt0eXAmcXVvdDs6ICZxdW90O3NldCZxdW90OyBvciAmcXVvdDt0eXAmcXVvdDs6ICZxdW90 O2V2ZW50JnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gMjksIDIwMTcgYXQg NToxNyBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgdG8gdHlwIGNs YWltLiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQo8c3BhbiBj bGFzcz0ibTIwOTI3MDM4MDcwOTMwNjQ1MTBob2VuemIiPlBoaWw8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gSnVuIDI5 LCAyMDE3LCBhdCA1OjAxIFBNLCBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtp bXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5zYWtpbXVyYUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29y cnkgZm9yIGEgdGFyZHkgcmVwbHksIGJ1dCZuYnNwOyYjNDM7MSBmb3IgdGhlIGJvdGggY2hhbmdl cy4gJ2V4cCcgY2xhaW0gcmVxdWlyZW1lbnQgaXMgYSBnb29kIHByYWN0aWNhbCBzdGVwIHdpdGgg YSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmluZyBzYWlkIHRoYXQsIEkgYmVs aWV2ZSBpbmZlcnJpbmcgbWVzc2FnZSB0eXBlcyBmcm9tIHRoZSBleGlzdGVuY2UvYWJzZW5jZSBv ZiBhIGNsYWltIGlzIG5vdCBhIGdvb2Qgc2VjdXJpdHkgcHJhY3RpY2UuIEkgd291bGQgbGlrZSB0 byBzZWUgYW4gZXhwbGljaXQgdHlwaW5nIHRocm91Z2ggJnF1b3Q7dHlwJnF1b3Q7IGNsYWltIGFk ZGVkIGFzIHdlbGwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1biAzMCwgMjAxNyBhdCA3OjA0IEFNIFBoaWwg SHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5j b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pay4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzky MjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0QXBwbGVNYWlsU2lnbmF0dXJlIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAx Mzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNwb2tlIHdpdGggTWlrZSBhbmQgaGUgd2lsbCBwb3N0IGhp cyBjaGFuZ2VzIHRvIFNFVCBpbiBhIG5ldyByZXZpc2lvbiBvdmVyIHRoZSB3ZWVrZW5kLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9 Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2 MDIxNTg5MDRBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5Mjcw MzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRB cHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4g MjksIDIwMTcsIGF0IDE6NTEgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHVuZGVyc3RhbmQgaXQgaXMgbmV3IGFuZCB0aGF0IHRoZXJlIGlzIGNvbnRlbnRp b24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNsZWFybHkgd2FudCBjb25z ZW5zdXMgZm9yIHVzIHRvIGJlIGRvbmUgd2l0aCB0aGUgZHJhZnQuIEkgdGhpbmsgaGF2aW5nIGl0 IGluIHRoZSBuZXh0IGRyYWZ0IGFuY2hvcnMgdGhlIGRpc2N1c3Npb24gc28gd2UgY2FuIGRpc2N1 c3MgYW5kIGFycml2ZSBhdCBjb25zZW5zdXMgb3IgYW4gYWx0ZXJuYXRpdmUuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHllcywgaXMgbGlrZSBhIG5ldyBkcmFmdCBwb3N0ZWQg c28gd2UgY2FuIGRpc2N1c3MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biAy OSwgMjAxNyBhdCAxMjo1OCBQTSBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlj ayw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlY3Rpb24gaXMgYSBicmFuZCBuZXcg c2VjdGlvbi4gSXQgc2VlbXMgdG8gbWUgdGhhdCBoYXMgbm90IGJlZW4gYW55IChvciBsaW1pdGVk KSBkaXNjdXNzaW9uIHRvIHdhcnJhbnQgcHV0dGluZyBpdCBpbiB0aGUgZG9jdW1lbnQuJm5ic3A7 IEl0IGNlcnRhaW5seSBjYW1lIHRvIG1lIGFzIGEgc3VycHJpc2UuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgdGhlIGlzc3VlIG9mIHRydXN0IG1vZGVsIG5lZWRzIHRvIGJlIGRp c2N1c3NlZC4mbmJzcDsgSXQgbWF5IG5vdCBiZWxvbmcgaGVyZSBhdCBhbGwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBhZHZpc2UuJm5ic3A7IERvIHlvdSB3YW50IGl0IHBvc3Rl ZCBpbiBzcGl0ZSBvZiBjb25zZW5zdXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PcmFjbGUgQ29y cG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdCAmYW1wOyBTdGFuZGFy ZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50 aWQuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlU cGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENf bExJR2smYW1wO209RHpodl8xYVRBaHpzeVFxMVVwQ083cWlXeHpBSEpYOHktX1ZHSkMzRUFDZyZh bXA7cz1mRVZ2RnNFcWtUbUNwWTZzSWFfR1ZfUzNHeTFneGhHNTZXYWJ3MjRHMExBJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVu dGlkLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDI5LCAyMDE3LCBhdCAxMjoyNSBQTSwgRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZGljay5oYXJkdEBnbWFpbC5jb208L3Nw YW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFBoaWw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndydCBhc2tpbmcgZm9yIG1vcmUgZGlzY3Vzc2lvbiwgSSBhcHByZWNpYXRl IHlvdSBtYWtpbmcgdGhlIHN1Z2dlc3Rpb24gb24gYmVoYWxmIG9mIHRoZSBjaGFpcnMuIEl0IGRv ZXMgc2VlbSB0aGVyZSBpcyBhIHJlYXNvbmFibGUgYW1vdW50IG9mIGRpc2N1c3Npb24gZ29pbmcg b24gbm93IHdvdWxkIHlvdSBub3QgYWdyZWU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkn ZCBsaWtlIHRvIGdldCB0aGUgZG9jIHVwZGF0ZWQgaW4gdGltZSBmb3IgUHJhZ3VlIHNvIHRoYXQg d2UgaGF2ZSBhIGNsZWFyIHJlZmVyZW5jZSBwb2ludCBmb3IgZGlzY3Vzc2lvbiB0aGVyZSBhbmQg dGhlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuY2xlYXIgd2h5IHlvdSB3 b3VsZCBwb3N0IGEgY2hhbmdlIHdoZW4gaXQgd2FzIE1pa2UgdGhhdCBkaWQgdGhpcyB3b3JrLiBB bSBJIG1pc3Npbmcgc29tZXRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlOiB3 b3VsZCB5b3UgdXBkYXRlIHRoZSBkb2Mgd2l0aCB3aGF0IHlvdSB0aGluayBpcyByb3VnaCBjb25z ZW5zdXMgd2hlbiB5b3UgaGF2ZSB0aW1lIHNvIHRoYXQgd2UgY2FuIGhhdmUgYSBjcmlzcCBkaXNj dXNzaW9uIGluIFByYWd1ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gMjgsIDIwMTcgYXQgNToz OCBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIG9uIHRoZSBleHAg cGFydC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIw OTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4 OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTczODI5MEFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5 MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0 Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcnQuIEkgd291bGQgbGlrZSB0 byBzZWUgbW9yZSBkaXNjdXNzaW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0Mzdt XzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTkyMTU5 NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4 MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0bV8t NzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTczODI5MEFwcGxlTWFpbFNpZ25hdHVy ZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGluIHRoZSB0aGUg dXNlIGNhc2VzLCB0aGVyZSBtYXkgYmUgY29tcGF0aWJpbGl0eSBpc3N1ZXMgaWYgZGlmZmVyZW50 IHNldCBwcm9maWxlcyBjYW5ub3QgYmUgc2VudCBvdmVyIHRoZSBzYW1lIHN0cmVhbS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4MDcwOTMw NjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEy NzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTczODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4 OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkx OTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlN1Y2ggcHJvZmlsZXMgc2hvdWxkIGF2b2lkIHRoaW5ncyBsaWtlIHJlcXVpcmluZyBzaWdu aW5nIGFuZCBlbmNyeXB0aW9uIHdpdGhvdXQgY29uc2lkZXJhdGlvbiByZWdhcmRpbmcgaG93IHRo ZXkgYXJlIHRyYW5zZmVycmVkLiZuYnNwOyBBbHNvIGtleSBtYW5hZ2VtZW50IG1pZ2h0IGJlIGJl dHRlciB0aWVkIHVwIGluIGhvdyB0aGUgc3RyZWFtcyBhcmUgbWFuYWdlcyBiZWNhdXNlIHRoZSBu ZXR3b3JrIHJlbGF0aW9uc2hpcA0KIG1heSBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyByYXRoZXIg dGhhbiB0aGUgZGF0YS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5 NjM2NjAyMTU4OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTczODI5MEFw cGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0 NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcy NzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGluaXRpYWwgcmVhY3Rpb24gaXMsIHRoZSBwcm9m aWxlcyBzaG91bGQgc3RpY2sgdG8gdGhlIGRhdGEgYW5kIHZhbGlkIGludGVycHJldGF0aW9uLiZu YnNwOzxicj4NCjxicj4NCklmIHRoZSBncm91cCBhZ3JlZXMgSSB3aWxsIG1lcmdlIHRoZSBleHAg YW5kIHBvc3Qgb3ZlciB0aGUgd2Vla2VuZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGlkPSJtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5 NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5 MjE1OTczODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDky NzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkw NG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWdu YXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIG1lcmdlIHRoZSBzZWNv bmQgcGFydCBpZiB0aGVyZSBpcyBhIHN0cm9uZyBhZ3JlZW1lbnQgdG8gZG8gc28uJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDkyNzAzODA3MDkzMDY0 NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcy NzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgaWQ9Im1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0 MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTky MTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMDky NzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkw NG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWdu YXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIEp1biAyOCwgMjAx NywgYXQgNToyNCBQTSwgV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5p c3NAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PndkZW5uaXNzQGdvb2dsZS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rIHlvdSBNaWtlIGZvciB3b3JraW5nIG9uIHRoaXMuIEknbSB2ZXJ5IGhhcHB5IHdp dGggdGhlIGNoYW5nZSByZWdhcmRpbmcgdGhlICZxdW90O2V4cCZxdW90OyBjbGFpbSwgYW5kIGJl bGlldmUgaXQgaXMgdGhlIGJlc3QgcmVzb2x1dGlvbiB0byB0aGUgJnF1b3Q7SUQgVG9rZW4mcXVv dDsgY29uZnVzaW9uIGNvbmNlcm4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ5IG1ha2lu ZyB0aGUgJnF1b3Q7ZXhwJnF1b3Q7IGNsYWltIHRoYXQgaXM8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0 LTJEaWV0Zi0yRHNlY2V2ZW50LTJEdG9rZW4tMkQwMS0yM3NlY3Rpb24tMkQyLjEmYW1wO2Q9RHdN RmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1w O3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1fWEY5 OTR6Vm4xX0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTVMOXFxSF9ldmts WC1IakRGOEtrWjJlNWJOYTZmWmMza0pJWEwycWZVV3MmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWxyZWFkeTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk5PVA0KIFJFQ09NTUVOREVEIGlu IHRoZSBjdXJyZW50IGRyYWZ0IGEgTVVTVCBOT1QsIHdlIGNhbiBwcm92aWRlIHRoZSBJRCBUb2tl bnMgYW5kIFNFVCB1bmlxdWVuZXNzIGd1YXJhbnRlZSB0aGF0IGlzIGRlc2lyZWQsIGFsbG93aW5n IHRoZXNlIHR3byB0eXBlcyBvZiBKV1RzIHRvIGJlIHVzZWQgd2l0aCBhIGNvbW1vbiBpc3N1ZXIu IFRoaXMgYWxzbyBhbGxvd3MgJnF1b3Q7c3ViJnF1b3Q7IHRvIGJlIHVzZWQgZm9yIGl0cyBpbnRl bmRlZCBwdXJwb3NlIChhcyBkZWZpbmVkDQogYnkgUkZDNzUxOSkgd2l0aG91dCBtb2RpZmljYXRp b24sIHdoaWNoIG90aGVyIHdvcmtpbmcgZ3JvdXBzIHRoYXQgd2lzaCB0byBwcm9maWxlIFNFVCBo YXZlIGV4cHJlc3NlZCBhbiBpbnRlcmVzdCB0byBkbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgYmVuZWZpdCB0aGUgY29tbXVuaXR5IHdpbGwgZ2FpbiBmcm9tIHRoZSBTRVQgc3RhbmRh cmQgb3ZlcmFsbCBpcyBhIHN0YW5kYXJkIHdheSB0byBleHByZXNzIGV2ZW50cyB0aGF0IHdvbid0 IGNvbmZsaWN0IHdpdGggSUQgVG9rZW4gKG5vICZxdW90O2lzcyZxdW90OyBwYXJ0aXRpb25pbmcg cmVxdWlyZWQpLiBXaXRoIE1pa2UncyBjaGFuZ2VzIHdlIGFjaGlldmUgdGhhdCwgYW5kIGluIGEg d2F5IHRoYXQgcmV0YWlucyB0aGUNCiBvcmlnaW5hbCBzaW1wbGljaXR5LCBleHRlbnNpYmlsaXR5 IGFuZCBnZW5lcmFsaXphYmlsaXR5IGdvYWxzIG9mIFNFVCBieSBub3QgcmVkZWZpbmluZyBhbnkg b2YgSldUJ3Mgc3RhbmRhcmQgY2xhaW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVuIDI4LCAyMDE3IGF0IDU6MDggUE0sIE1pa2UgSm9uZXMg Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgZm9sa3MsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FudGVkIHRvIGdpdmUgeW91 IGEgaGVhZHMtdXAgYWJvdXQgdHdvIFNFVCBzcGVjIHVwZGF0ZXMgaW4gdGhlIGN1cnJlbnQgZWRp dG9y4oCZcyBkcmFmdCBiZWZvcmUgdGhleSBhcmUgcHVibGlzaGVkLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmlyc3Qgc29sdmVzIHRo ZSBwb3RlbnRpYWwgSUQgVG9rZW4gLyBTRVQgY29uZnVzaW9uIHByb2JsZW0gYnkgcmVxdWlyaW5n IHRoYXQgU0VUcyBub3QgaW5jbHVkZSBhIHRvcC1sZXZlbCDigJxleHDigJ0gY2xhaW0gd2hlbiBJ RCBUb2tlbnMgY291bGQgYWxzbyBiZSBnZW5lcmF0ZWQgYnkgdGhlIHNhbWUgaXNzdWVyLiZuYnNw OyBCZWNhdXNlIOKAnGV4cOKAnSBpcyBhIHJlcXVpcmVkIElEIFRva2VuIGNsYWltLCBTRVRzIHdv dWxkDQogdGhlcmVmb3JlIGJlIHJlamVjdGVkIGJ5IGV4aXN0aW5nIElEIFRva2VuIHZhbGlkYXRp b24gY29kZS4mbmJzcDsgTm90ZSB0aGF0IHRoaXMgc29sdXRpb24gaXMgYWxyZWFkeSByZWNvbW1l bmRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4mbmJzcDsgVGhlIGVkaXRvcuKAmXMgZHJhZnQgdXBk YXRlIG1ha2VzIHRoaXMgc29sdXRpb24gbWFuZGF0b3J5LiZuYnNwOyBUaGlzIHByb3ZpZGVzIGEg c2ltcGxlIGFuZCBkdXJhYmxlIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtIHdlIGFncmVlZA0KIHRv IHNvbHZlIGF0IElFVEYgOTggaW4gQ2hpY2FnbyBhbmQgdGhhdCBoYXMgYmVlbiB0aGUgc3ViamVj dCBvZiBtdWNoIGRpc2N1c3Npb24gc2luY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzZWNvbmQgYWRkcyB0aGUgZm9sbG93aW5nIG5l dyBzZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0OjI0LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlJlcXVpcmVtZW50cyBmb3IgU0VUIFByb2ZpbGVzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4w cHQ7bWFyZ2luLXJpZ2h0OjI0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlByb2ZpbGUgU3BlY2lm aWNhdGlvbnMgZm9yIFNFVHMgZGVmaW5lIHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRz IGNvbmZvcm1pbmcgdG8gdGhhdCBTRVQgcHJvZmlsZSBhbmQgcnVsZXMgZm9yIHZhbGlkYXRpbmcg dGhvc2UgU0VUcy4gVGhlIHN5bnRheCBkZWZpbmVkIGJ5DQogcHJvZmlsaW5nIHNwZWNpZmljYXRp b25zIGluY2x1ZGVzIHdoYXQgY2xhaW1zIGFuZCBldmVudCBwYXlsb2FkIHZhbHVlcyBhcmUgdXNl ZCBieSBTRVRzIHV0aWxpemluZyB0aGUgcHJvZmlsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MjQuMHB0O21hcmdpbi1yaWdodDoyNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+RGVmaW5pbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgU0VUIGNv bnRlbnRzIGZvciBTRVRzIHV0aWxpemluZyB0aGUgcHJvZmlsZSBpcyBlcXVhbGx5IGltcG9ydGFu dC4gUG9zc2libHkgbW9zdCBpbXBvcnRhbnQgaXMgZGVmaW5pbmcgdGhlIHByb2NlZHVyZXMgdXNl ZCB0byB2YWxpZGF0ZQ0KIHRoZSBTRVQgaXNzdWVyIGFuZCB0byBvYnRhaW4gdGhlIGtleXMgY29u dHJvbGxlZCBieSB0aGUgaXNzdWVyIHRoYXQgd2VyZSB1c2VkIGZvciBjcnlwdG9ncmFwaGljIG9w ZXJhdGlvbnMgdXNlZCBpbiB0aGUgSldUIHJlcHJlc2VudGluZyB0aGUgU0VULiBGb3IgaW5zdGFu Y2UsIHNvbWUgcHJvZmlsZXMgbWF5IGRlZmluZSBhbiBhbGdvcml0aG0gZm9yIHJldHJpZXZpbmcg dGhlIFNFVCBpc3N1ZXIncyBrZXlzIHRoYXQgdXNlcyB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aXNz PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp ZiI+Y2xhaW0NCiB2YWx1ZSBhcyBpdHMgaW5wdXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7bWFyZ2luLXJpZ2h0OjI0LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0 LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPlByb2ZpbGUgU3BlY2lmaWNhdGlvbnMgTVVTVCBjbGVhcmx5IHNw ZWNpZnkgdGhlIHN0ZXBzIHRoYXQgYSByZWNpcGllbnQgb2YgYSBTRVQgdXRpbGl6aW5nIHRoYXQg cHJvZmlsZSBNVVNUIHBlcmZvcm0gdG8gdmFsaWRhdGUgdGhhdCB0aGUgU0VUIGlzIGJvdGggc3lu dGFjdGljYWxseQ0KIGFuZCBzZW1hbnRpY2FsbHkgdmFsaWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKAmXMgaW5jbHVkZWQg dG8gaW5mb3JtIHByb2ZpbGUgd3JpdGVycyBhYm91dCB3aGF0IHRoZXkgbXVzdCBkbyB0byBiZSBh YmxlIHRvIHVzZSBTRVRzIHNlY3VyZWx5LiZuYnNwOyBXaGlsZSBtdWNoIG9mIHRoZSBkaXNjdXNz aW9uIGFzIG9mIGxhdGUgaGFzIGJlZW4gYWJvdXQgc3ludGF4LCBzZW1hbnRpY3MgaXMgZXF1YWxs eSBpbXBvcnRhbnQsIGFuZCBtdXN0IGJlIGNvbnNpZGVyZWQgYnkgcHJvZmlsZSB3cml0ZXJzIGFu ZA0KIGRlcGxveWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoYXQgdGhlIG5ldyBzZWN0aW9uIGNvbnRhaW5zIG9ubHkg c3RhdGVtZW50cyB0aGF0IGFyZSBhbHJlYWR5IGZhY3R1YWxseSBhY2N1cmF0ZSByZXF1aXJlbWVu dHMgYnV0IHRoYXQgd2VyZSBwcmV2aW91c2x5IHVuc3RhdGVkLiZuYnNwOyBUaGUgZWRpdG9y4oCZ cyBkcmFmdCBtYWtlcyB0aGVzZSByZXF1aXJlbWVudHMgZXhwbGljaXQuJm5ic3A7IEZlZWRiYWNr IG9uIGhvdyB0byBtYWtlIHRoZXNlIHJlcXVpcmVtZW50cw0KIGV2ZW4gbW9yZSBjbGVhciwgaXMg b2YgY291cnNlLCB3ZWxjb21lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJl c3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPV9YRjk5NHpWbjFf QWVTLUN6U3RxT1FhVlFwc2RqanZmQnkzNVMwbzd0SDAmYW1wO3M9M3MxR0NjLTNnMktVX3BONkh2 V1ZIZ1dCSlhzNk9HUFk4Sy1uRmFxVXhLUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1fWEY5OTR6Vm4xX0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTNz MUdDYy0zZzJLVV9wTjZIdldWSGdXQkpYczZPR1BZOEstbkZhcVV4S1EmYW1wO2U9PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1l dmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRm Lm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NY NVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktl NENfbExJR2smYW1wO209RVRiR0l4UlpMY1FmWVp0WVVWazZUN0hrd1lHZlh4LTAyd3kzcDQ1b1hH USZhbXA7cz1sTVNvd2JEbmpVZVhFN3pMcHJHSFNQUmd4Wk1oRVp1SXFUa0xUZmdCTkdFJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3Vic2NyaWJlIHRvIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9faGFyZHR3YXJlLmNvbV8mYW1wO2Q9RHdNRmFRJmFtcDtj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJp UnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1FVGJHSXhSWkxjUWZZ WnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdRJmFtcDtzPTNVZDF2MnBHWER3NDVnOUZrbUl3 dFdvNDV6ZEZHX05TZ2NqY2Y2a0huRXcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+SEFSRFRXQVJFPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bWFpbA0KIGxpc3QgdG8gbGVhcm4gYWJvdXQg cHJvamVjdHMgSSBhbSB3b3JraW5nIG9uITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7 Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTVi aVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209RVRiR0l4UlpMY1Fm WVp0WVVWazZUN0hrd1lHZlh4LTAyd3kzcDQ1b1hHUSZhbXA7cz1sTVNvd2JEbmpVZVhFN3pMcHJH SFNQUmd4Wk1oRVp1SXFUa0xUZmdCTkdFJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZh bXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdT YksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFt cDttPUVUYkdJeFJaTGNRZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9YR1EmYW1wO3M9bE1T b3diRG5qVWVYRTd6THByR0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZhbXA7ZT08L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUZhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209RHpodl8xYVRBaHpzeVFx MVVwQ083cWlXeHpBSEpYOHktX1ZHSkMzRUFDZyZhbXA7cz1mSzhSWG4wMWFpeG9Zc0Nsa2t1ZGdK R0V4SDBkZHY2Q3YzS1hGWTRQdEMwJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPkhBUkRUV0FSRTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0IHBy b2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9 RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAm YW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1s Rmk5eDNYemhCMU9Id2hWbm1IMmFyaWRXMS13MVRUY0hCMkhtZWtjcmpNJmFtcDtzPWxkMGxpNGRx YWo2UzhtdUdzeHBCY0hCY1kxUGx5TEJMSi1UY3lFcnF6MDgmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5OYXQgU2FraW11cmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNoYWlybWFuIG9mIHRoZSBCb2Fy ZCwgT3BlbklEIEZvdW5kYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB05049620FF96A3327DEC735DF5D30CY4PR21MB0504namp_-- From nobody Fri Jun 30 14:08:16 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4AC12EA97 for ; Fri, 30 Jun 2017 14:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KWWmGv6brUA for ; Fri, 30 Jun 2017 14:08:03 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D85129B66 for ; Fri, 30 Jun 2017 14:08:03 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id r30so108714518qtc.0 for ; Fri, 30 Jun 2017 14:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gJ2h2IKxI7OkxgI6cIeAkENrW5IuvelF9MO/z5nBQU4=; b=r/aRKxgFtknMxJ39IqPA/LWoXt9B3N0KJ3Z7rDopzQ4Y6bo8Icll1gAV45tJQen3Nr zS+JH1ECF3IdhlqmDCn6wAKAyhQw5F0xp6g/2PA2vKaCG78Wm2nMFeOGvxnmSlryCKnb Kxe/+JG8Em+QZVQH0GqYnZUu5q7jtt+GcXqxxn8OaAMaXUi49FHjEreyaeF5Yho2IKke fGmiCMB6b12kshKQXcOplBYxRZNfOsGrDd/0kMRZa8RK6VKTxRiZcT5LRIYG2Rl0m716 TDx3EqDTfD1sY1IwSj+a6L3BkgFviqefXaTdFG4scE9JJCLZCCthdNXsZTPbZNEXe4sn uZcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gJ2h2IKxI7OkxgI6cIeAkENrW5IuvelF9MO/z5nBQU4=; b=KGcv3fCxrsxcKd/3A3/LENx8TQZii52s0/EQvZbF+0AORpZH6/kRYGANMK3BcgQmnN MLgw3+2NkisFsgv9gdQahs5x5b7mXpEyeEOfB9aKckmjPS1cusiNpKH1PYXtk4nqJ0qu 7FMfyo7aGRIDZMcbomm7aa1lNHbXKrnbTwxEmXesQd+nAMzwWa8k4NRR3yP5SxD73Q67 z24XNwnEwIo+VEjFZmxPpPYocfZI/Aivm9CUyHTsHbH+nwyZFRr+jc3vzhb1wtXGOE8D nLJFtSgu/pjjpbnd2Xq3OvBbzO+jXTI9Ng5TbypoBRoS+A/K3ORJmxWMa9Ll+cRLz+pq y8Gw== X-Gm-Message-State: AKS2vOw+rRt64sYJ6V+LtedUca7dPmYTXPGjuvpmd2D83z0c6FLCV0Aj 7J0h7wePuuy6aSpeecbm/ynyHPLLnUDG X-Received: by 10.200.49.18 with SMTP id g18mr30806790qtb.118.1498856881985; Fri, 30 Jun 2017 14:08:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.242 with HTTP; Fri, 30 Jun 2017 14:07:41 -0700 (PDT) In-Reply-To: <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> From: William Denniss Date: Fri, 30 Jun 2017 14:07:41 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Phil Hunt , Nat Sakimura , "id-event@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="001a1138eb9a05b4d8055333d042" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:08:15 -0000 --001a1138eb9a05b4d8055333d042 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is application/secevent+jwt this following the RFC3023 pattern? i.e. indicating that it's a secevent primarily, but also a JWT? On Fri, Jun 30, 2017 at 2:05 PM, Justin Richer wrote: > Unless there=E2=80=99s an encoding for security events other than JWT, wo= uldn=E2=80=99t > application/secevent suffice? > > =E2=80=94 Justin > > On Jun 30, 2017, at 12:56 PM, Mike Jones > wrote: > > There had already been discussions, both in Chicago, and in the JWT BCP > context, that if we were going to use a type identifier, we would use the > existing =E2=80=9Ctyp=E2=80=9D header parameter and not create a new clai= m. This is a MIME > type, with the ability to omit =E2=80=9Capplication/=E2=80=9D for space r= easons, if desired. > > Since there appears to be broad interest in having the ability to use > explicit typing of the SET, I will plan to define the > =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the SET draft bef= ore publishing. > SETs could then include the =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt= =E2=80=9D header parameter value to > provide explicit typing. Unless I hear objections soon, I will proceed o= n > this basis. > > -- Mike > > *From:* William Denniss [mailto:wdenniss@google.com = ] > > *Sent:* Friday, June 30, 2017 9:33 AM > *To:* Phil Hunt (IDM) > *Cc:* Nat Sakimura ; Dick Hardt ; > Mike Jones ; id-event@ietf.org > *Subject:* Re: [Id-event] Heads-up about SET spec updates > > +1 to typ. > > So "typ": "set" or "typ": "event"? > > On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) > wrote: > > +1 to typ claim. > > Phil > > > On Jun 29, 2017, at 5:01 PM, Nat Sakimura wrote: > > Sorry for a tardy reply, but +1 for the both changes. 'exp' claim > requirement is a good practical step with a backward compatibility. > Having said that, I believe inferring message types from the > existence/absence of a claim is not a good security practice. I would lik= e > to see an explicit typing through "typ" claim added as well. > > Nat > > On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) > wrote: > > Ok. > > I spoke with Mike and he will post his changes to SET in a new revision > over the weekend. > > Phil > > > On Jun 29, 2017, at 1:51 PM, Dick Hardt wrote: > > I understand it is new and that there is contention. > > We clearly want consensus for us to be done with the draft. I think havin= g > it in the next draft anchors the discussion so we can discuss and arrive = at > consensus or an alternative. > > So yes, is like a new draft posted so we can discuss. > > On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt wrote: > > Dick, > > The section is a brand new section. It seems to me that has not been any > (or limited) discussion to warrant putting it in the document. It > certainly came to me as a surprise. > > I think the issue of trust model needs to be discussed. It may not belon= g > here at all. > > Please advise. Do you want it posted in spite of consensus? > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > > phil.hunt@oracle.com > > > On Jun 29, 2017, at 12:25 PM, Dick Hardt wrote: > > > Hi Phil > > wrt asking for more discussion, I appreciate you making the suggestion on > behalf of the chairs. It does seem there is a reasonable amount of > discussion going on now would you not agree? > > I'd like to get the doc updated in time for Prague so that we have a clea= r > reference point for discussion there and then. > > Unclear why you would post a change when it was Mike that did this work. > Am I missing something? > > Mike: would you update the doc with what you think is rough consensus whe= n > you have time so that we can have a crisp discussion in Prague? > > > > On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) > wrote: > > I agree on the exp part. > > Regarding the second part. I would like to see more discussion. > > For example, in the the use cases, there may be compatibility issues if > different set profiles cannot be sent over the same stream. > > Such profiles should avoid things like requiring signing and encryption > without consideration regarding how they are transferred. Also key > management might be better tied up in how the streams are manages because > the network relationship may define the requirements rather than the data= . > > My initial reaction is, the profiles should stick to the data and valid > interpretation. > > If the group agrees I will merge the exp and post over the weekend. > > I can merge the second part if there is a strong agreement to do so. > > Thanks! > > Phil > > > On Jun 28, 2017, at 5:24 PM, William Denniss wrote: > > Thank you Mike for working on this. I'm very happy with the change > regarding the "exp" claim, and believe it is the best resolution to the "= ID > Token" confusion concern. > > By making the "exp" claim that is already > > NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID > Tokens and SET uniqueness guarantee that is desired, allowing these two > types of JWTs to be used with a common issuer. This also allows "sub" to = be > used for its intended purpose (as defined by RFC7519) without modificatio= n, > which other working groups that wish to profile SET have expressed an > interest to do > > The benefit the community will gain from the SET standard overall is a > standard way to express events that won't conflict with ID Token (no "iss= " > partitioning required). With Mike's changes we achieve that, and in a way > that retains the original simplicity, extensibility and generalizability > goals of SET by not redefining any of JWT's standard claims. > > > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones > wrote: > > Hi folks, > > I wanted to give you a heads-up about two SET spec updates in the current > editor=E2=80=99s draft before they are published. > > The first solves the potential ID Token / SET confusion problem by > requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim w= hen ID Tokens > could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID > Token claim, SETs would therefore be rejected by existing ID Token > validation code. Note that this solution is already recommended in the > specification. The editor=E2=80=99s draft update makes this solution man= datory. > This provides a simple and durable solution to the problem we agreed to > solve at IETF 98 in Chicago and that has been the subject of much > discussion since. > > The second adds the following new section: > > Requirements for SET Profiles > > Profile Specifications for SETs define the syntax and semantics of SETs > conforming to that SET profile and rules for validating those SETs. The > syntax defined by profiling specifications includes what claims and event > payload values are used by SETs utilizing the profile. > > Defining the semantics of the SET contents for SETs utilizing the profile > is equally important. Possibly most important is defining the procedures > used to validate the SET issuer and to obtain the keys controlled by the > issuer that were used for cryptographic operations used in the JWT > representing the SET. For instance, some profiles may define an algorithm > for retrieving the SET issuer's keys that uses the iss claim value as its > input. > > Profile Specifications MUST clearly specify the steps that a recipient of > a SET utilizing that profile MUST perform to validate that the SET is bot= h > syntactically and semantically valid. > > It=E2=80=99s included to inform profile writers about what they must do t= o be able > to use SETs securely. While much of the discussion as of late has been > about syntax, semantics is equally important, and must be considered by > profile writers and deployers. > > I believe that the new section contains only statements that are already > factually accurate requirements but that were previously unstated. The > editor=E2=80=99s draft makes these requirements explicit. Feedback on ho= w to make > these requirements even more clear, is of course, welcomed. > > Best > wishes, > -- Mike > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS- > CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K- > nFaqUxKQ&e=3D > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3D > lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D > > > > -- > Subscribe to the HARDTWARE > > mail list to learn about projects I am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > --001a1138eb9a05b4d8055333d042 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is application/secevent+j= wt this following the RFC3023 pattern? i.e. indicating that it's a sece= vent primarily, but also a JWT?
=
On Fri, Jun 30, 2017 at 2:05 PM, Justin Rich= er <jricher@mit.edu> wrote:
=
Unless there=E2=80=99s an encoding for = security events other than JWT, wouldn=E2=80=99t application/secevent suffi= ce?

=C2= =A0=E2=80=94 Justin

On Jun 30, 2017, at 12:56 PM, Mike Jones &l= t;Michael.= Jones@microsoft.com> wrote:

There had already been discu= ssions, both in Chicago, and in the JWT BCP context, that if we were going = to use a type identifier, we would use the existing =E2=80=9Ctyp=E2=80=9D h= eader parameter and not create a new claim.=C2=A0 This is a MIME type, with= the ability to omit =E2=80=9Capplication/=E2=80=9D for space reasons, if d= esired.
=C2=A0
Since there appears to be broad interest in having the ability to us= e explicit typing of the SET, I will plan to define the =E2=80=9Capplicatio= n/secevent+jwt=E2=80=9D MIME type in the SET draft before publishing.=C2=A0= SETs could then include the =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2= =80=9D header parameter value to provide explicit typing.=C2=A0 Unless I he= ar objections soon, I will proceed on this basis.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=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
From:=C2=A0William Denniss [<= a href=3D"mailto:wdenniss@google.com" target=3D"_blank">mailto:wdenniss@goo= gle.com]=C2= =A0
Sent:=C2=A0Friday, June 30, 2017 9:33 AM
To:=C2=A0Phil Hunt = (IDM) <phil.hu= nt@oracle.com>
Cc:=C2=A0Nat Sakimura <sakimura@gmail.com>; Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om>; Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject:<= span class=3D"m_-5902027253108218876Apple-converted-space">=C2=A0Re:= [Id-event] Heads-up about SET spec updates
= =C2=A0
+1 to typ.
=C2=A0
So "typ"= ;: "set" or "typ": "event"?
=C2=A0
On Thu, Jun= 29, 2017 at 5:17 PM, Phil Hunt (IDM) <p= hil.hunt@oracle.com> wrote:
+1 to typ claim.=C2=A0

Phil


On Jun 29, 2017, at 5:01 PM, Nat Sakimura <sakimura@gmail.com> wrote:

=
= Sorry for a tardy reply, but=C2=A0+1 for the both changes. 'exp' cl= aim requirement is a good practical step with a backward compatibility.=C2= =A0
Having said that, I believe inferring= message types from the existence/absence of a claim is not a good security= practice. I would like to see an explicit typing through "typ" c= laim added as well.=C2=A0
= =C2=A0
Nat
=
=C2=A0
On Fri, Jun 30, 201= 7 at 7:04 AM Phil Hunt (IDM) <phil.hunt@= oracle.com> wrote:
Ok.=C2=A0
=C2=A0
I spoke with Mike and he will post h= is changes to SET in a new revision over the weekend.=C2=A0
= =C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">Phil


On Jun 29, 2017, at 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

= I understand it is new and that there is contention.=C2=A0
=C2=A0
We c= learly want consensus for us to be done with the draft. I think having it i= n the next draft anchors the discussion so we can discuss and arrive at con= sensus or an alternative.=C2=A0
= =C2=A0
So yes, is like a new draft pos= ted so we can discuss.=C2=A0
=C2= =A0
On Thu, Jun 29, 2017 at 12:58 PM Phil H= unt <phil.hunt@oracle.com> wrote:=
Dick,
=C2=A0
The section is a brand new section. It seems to me that has not = been any (or limited) discussion to warrant putting it in the document.=C2= =A0 It certainly came to me as a surprise.
=C2=A0
I think the issue of= trust model needs to be discussed.=C2=A0 It may not belong here at all.=
=C2=A0
=
Please advise.=C2=A0 Do you want it posted in spite of consensus?=
=C2=A0
<= div>
<= /div>
=C2=A0
=
= On Jun 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
= =C2=A0
Hi = Phil
=C2=A0
wrt asking for more discussion, I appreciate you making the sugg= estion on behalf of the chairs. It does seem there is a reasonable amount o= f discussion going on now would you not agree?
=C2=A0
I'd like to = get the doc updated in time for Prague so that we have a clear reference po= int for discussion there and then.
= =C2=A0
Unclear why you would p= ost a change when it was Mike that did this work. Am I missing something?
=C2=A0
Mike: would you update the doc with what you think is rough cons= ensus when you have time so that we can have a crisp discussion in Prague?<= u>
=C2=A0
=C2=A0
<= /u>=C2=A0
On Wed, Jun 28, 2017 at 5:38 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com>= wrote:
I agre= e on the exp part.=C2=A0
=C2=A0
Regarding the second part. I= would like to see more discussion.=C2=A0
=C2=A0
For exampl= e, in the the use cases, there may be compatibility issues if different set= profiles cannot be sent over the same stream.=C2=A0
=C2=A0
= Such profiles should avoid things like requiring signing and encryption wit= hout consideration regarding how they are transferred.=C2=A0 Also key manag= ement might be better tied up in how the streams are manages because the ne= twork relationship may define the requirements rather than the data.=C2=A0<= u>
=C2=A0
My initial reaction is, the profiles should stick to = the data and valid interpretation.=C2=A0

If the group agrees I will = merge the exp and post over the weekend.=C2=A0
=C2=A0
I can = merge the second part if there is a strong agreement to do so.=C2=A0=
=C2=A0
Thanks!

Ph= il


On J= un 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you M= ike for working on this. I'm very happy with the change regarding the &= quot;exp" claim, and believe it is the best resolution to the "ID= Token" confusion concern.
= =C2=A0
By making the "exp" c= laim that is=C2= =A0a= lready=C2= =A0NOT RECOMMENDED in the current draft a MUST NOT, we can provide t= he ID Tokens and SET uniqueness guarantee that is desired, allowing these t= wo types of JWTs to be used with a common issuer. This also allows "su= b" to be used for its intended purpose (as defined by RFC7519) without= modification, which other working groups that wish to profile SET have exp= ressed an interest to do
=C2= =A0
The benefit the community will gain fr= om the SET standard overall is a standard way to express events that won= 9;t conflict with ID Token (no "iss" partitioning required). With= Mike's changes we achieve that, and in a way that retains the original= simplicity, extensibility and generalizability goals of SET by not redefin= ing any of JWT's standard claims.
=C2=A0
=C2=A0
On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote= :
Hi folks,=
=C2=A0
I wanted to = give you a heads-up about two SET spec updates in the current editor=E2=80= =99s draft before they are published.
=C2=A0
The first solves the potential ID Token / SET c= onfusion problem by requiring that SETs not include a top-level =E2=80=9Cex= p=E2=80=9D claim when ID Tokens could also be generated by the same issuer.= =C2=A0 Because =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs wou= ld therefore be rejected by existing ID Token validation code.=C2=A0 Note t= hat this solution is already recommended in the specification.=C2=A0 The ed= itor=E2=80=99s draft update makes this solution mandatory.=C2=A0 This provi= des a simple and durable solution to the problem we agreed to solve at IETF= 98 in Chicago and that has been the subject of much discussion since.
=C2=A0
The second add= s the following new section:
=C2=A0<= /u>
Requirements for SET Profiles
=
=C2=A0
Profile Specifications= for SETs define the syntax and semantics of SETs conforming to that SET pr= ofile and rules for validating those SETs. The syntax defined by profiling = specifications includes what claims and event payload values are used by SE= Ts utilizing the profile.
=C2=A0
Defining the semantics of the SET contents = for SETs utilizing the profile is equally important. Possibly most importan= t is defining the procedures used to validate the SET issuer and to obtain = the keys controlled by the issuer that were used for cryptographic operatio= ns used in the JWT representing the SET. For instance, some profiles may de= fine an algorithm for retrieving the SET issuer's keys that uses the=C2=A0iss= =C2=A0claim value as its input.
= =C2=A0
Profile Specifications MUST clea= rly specify the steps that a recipient of a SET utilizing that profile MUST= perform to validate that the SET is both syntactically and semantically va= lid.
=C2=A0
=C2=A0=
I believe that the new section contains only = statements that are already factually accurate requirements but that were p= reviously unstated.=C2=A0 The editor=E2=80=99s draft makes these requiremen= ts explicit.=C2=A0 Feedback on how to make these requirements even more cle= ar, is of course, welcomed.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike
=C2=A0
=C2=A0


________________= _______________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



=C2=A0
--=C2=A0
<= div>
Subscribe to the=C2=A0HARDTWARE=C2=A0mail l= ist to learn about projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
=
--=C2=A0
Subscribe to the=C2=A0HARDTWARE=C2=A0mail list to = learn about projects I am working on!
=
______________________= _________________________
Id-event mailing list
Id-event@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/id-event
--=C2=A0

Nat Sakimu= ra

Chairman of the Board, OpenID Foundation

=C2=A0
_______________________________________________
Id-event mailing list
Id= -event@ietf.org
https://www= .ietf.org/mailman/listinfo/id-event

--001a1138eb9a05b4d8055333d042-- From nobody Fri Jun 30 14:08:44 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2812EAB9 for ; Fri, 30 Jun 2017 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1npqiKLTBWa for ; Fri, 30 Jun 2017 14:08:39 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0110.outbound.protection.outlook.com [104.47.33.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4035F129B66 for ; Fri, 30 Jun 2017 14:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3CuNT/vj8kLd25Za805viDGebF9X0U8SheiLR1GtoOs=; b=e9wdRtAo1rgkLicIoT9vCHOPGYp6UneD3chVxIQepnOJEKHYTBsqWi56Wkl3N65Xdkm1iRVV69q0vwYzN2uw1LqfdpcngPNHCBSJ6FIps9U8ZJty7E9UCKIgXHMBl2raX0xchLrMWW4157XN6nu+fckHogdN/S1Op1TdgjNIf2Q= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0631.namprd21.prod.outlook.com (10.175.115.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.5; Fri, 30 Jun 2017 21:08:36 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1240.007; Fri, 30 Jun 2017 21:08:36 +0000 From: Mike Jones To: William Denniss , Justin Richer CC: Phil Hunt , Nat Sakimura , "id-event@ietf.org" , Dick Hardt Thread-Topic: [Id-event] Heads-up about SET spec updates Thread-Index: AdLwa3VhxmOh1ap9Sxqj4ofmRP4gvAAApZIAAACBMYAAJ1aBgAABJWgAAAHadAAAApHigAAEEu8AAACVdYAAIhDoAAAAmlLgAAjl/4AAABREgAAABzng Date: Fri, 30 Jun 2017 21:08:35 +0000 Message-ID: References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-30T14:08:34.1248353-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0631; 7:P0iDGGRpC7s+VGVxnisibFIObRI81z47du3nWpjdBN6aUxCWbmdAiRz/ZcZHK/rTjswKQ4zUjVhhkVUF8DchTJGiU5tzRuzJ1pVYNzlIaBjdRvny9PDoV4q3geNExMDsiock+xg+Sxe+EQA2i3kZ7ranPj+scC9RJgR/w/qOXxYASf6fYoKrLuIVXXIRpX099YzPNEf401/nO6g6GymxaTk4nvFBgv1EvKjY2wJyTtbv8vi3thk37apfb+j/N/HV130lrJrLRVtjXal98C2b9T3fn99cqBux4XgQcy0A5hPEWidwtIT9T0OqDPvo7o9txkKC49k1cSUCAnxWGDiTZQz3QNbcSy0hVtFMIThl7Q20B6Kr6c7UoWN0Mi5tXKhQPLODxRSxdgCIPJGR8s2BpykDzebPf8gCE4Xcm/3naE9Z0rY0/q8bqA4DPE50iQ5dZdU/+RMT08GDnNwdGlB5aiVsul8E2GJpjrY8XvUgNoJPb20QpCmhLRnvqsK2N3lnzNkTuSo6jcgB9ChP/jlwzR7Cw/oJ5FmHVUmgaZVfBqrdUJD1xOBpxa9C7v5DZufH7lK+VwDniNpTldowKpIDr5W+0GJU8U2GKtyBhHd4LLN1Yafnf15AbZEBsA8FQ4cFhRMhZ3xoe4DVIy9xA8VeAwWblj87B8NFd/Y3tAZj+SL9TuanCBxCDe1slwnahu5YnL2aXey/yObJBF1K6595N/FozIC9/AUIwcs4VkrFV0OF1bDZ0lKLFRopnC3iWA4t4ScgajFIw8JTKpdMjxKX199Zab+v5zB5N8EXyDuKKHD/z9AhWIc3u1gG48ovLSJW x-ms-office365-filtering-correlation-id: 97b324a1-38e9-4134-7a69-08d4bffc2c83 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0631; x-ms-traffictypediagnostic: CY4PR21MB0631: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(10436049006162)(26388249023172)(236129657087228)(192374486261705)(90097320859284)(211936372134217)(100405760836317)(148574349560750)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(2017060910020)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0631; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0631; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(377454003)(24454002)(76104003)(78124002)(6116002)(3660700001)(74316002)(790700001)(10290500003)(102836003)(53946003)(53546010)(55016002)(25786009)(2420400007)(7736002)(3280700002)(81166006)(14454004)(4326008)(54906002)(72206003)(50986999)(236005)(6306002)(93886004)(38730400002)(54356999)(99286003)(6436002)(8676002)(2171002)(9686003)(53936002)(39060400002)(5005710100001)(10090500001)(2900100001)(76176999)(189998001)(6506006)(2906002)(7110500001)(6246003)(8936002)(478600001)(15650500001)(966005)(86362001)(77096006)(33656002)(7696004)(19609705001)(5660300001)(86612001)(8990500004)(575784001)(606006)(2950100002)(54896002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0631; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504BE96F3888DE13F528EC1F5D30CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 21:08:36.2647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0631 Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:08:43 -0000 --_000_CY4PR21MB0504BE96F3888DE13F528EC1F5D30CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzDQoNCkZyb206IFdpbGxpYW0gRGVubmlzcyBbbWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb21d DQpTZW50OiBGcmlkYXksIEp1bmUgMzAsIDIwMTcgMjowOCBQTQ0KVG86IEp1c3RpbiBSaWNoZXIg PGpyaWNoZXJAbWl0LmVkdT4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+OyBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPjsgTmF0IFNha2ltdXJhIDxz YWtpbXVyYUBnbWFpbC5jb20+OyBpZC1ldmVudEBpZXRmLm9yZzsgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBIZWFkcy11cCBhYm91dCBT RVQgc3BlYyB1cGRhdGVzDQoNCklzIGFwcGxpY2F0aW9uL3NlY2V2ZW50K2p3dCB0aGlzIGZvbGxv d2luZyB0aGUgUkZDMzAyMyBwYXR0ZXJuPyBpLmUuIGluZGljYXRpbmcgdGhhdCBpdCdzIGEgc2Vj ZXZlbnQgcHJpbWFyaWx5LCBidXQgYWxzbyBhIEpXVD8NCg0KT24gRnJpLCBKdW4gMzAsIDIwMTcg YXQgMjowNSBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVy QG1pdC5lZHU+PiB3cm90ZToNClVubGVzcyB0aGVyZeKAmXMgYW4gZW5jb2RpbmcgZm9yIHNlY3Vy aXR5IGV2ZW50cyBvdGhlciB0aGFuIEpXVCwgd291bGRu4oCZdCBhcHBsaWNhdGlvbi9zZWNldmVu dCBzdWZmaWNlPw0KDQog4oCUIEp1c3Rpbg0KDQpPbiBKdW4gMzAsIDIwMTcsIGF0IDEyOjU2IFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGVyZSBoYWQgYWxyZWFkeSBiZWVuIGRp c2N1c3Npb25zLCBib3RoIGluIENoaWNhZ28sIGFuZCBpbiB0aGUgSldUIEJDUCBjb250ZXh0LCB0 aGF0IGlmIHdlIHdlcmUgZ29pbmcgdG8gdXNlIGEgdHlwZSBpZGVudGlmaWVyLCB3ZSB3b3VsZCB1 c2UgdGhlIGV4aXN0aW5nIOKAnHR5cOKAnSBoZWFkZXIgcGFyYW1ldGVyIGFuZCBub3QgY3JlYXRl IGEgbmV3IGNsYWltLiAgVGhpcyBpcyBhIE1JTUUgdHlwZSwgd2l0aCB0aGUgYWJpbGl0eSB0byBv bWl0IOKAnGFwcGxpY2F0aW9uL+KAnSBmb3Igc3BhY2UgcmVhc29ucywgaWYgZGVzaXJlZC4NCg0K U2luY2UgdGhlcmUgYXBwZWFycyB0byBiZSBicm9hZCBpbnRlcmVzdCBpbiBoYXZpbmcgdGhlIGFi aWxpdHkgdG8gdXNlIGV4cGxpY2l0IHR5cGluZyBvZiB0aGUgU0VULCBJIHdpbGwgcGxhbiB0byBk ZWZpbmUgdGhlIOKAnGFwcGxpY2F0aW9uL3NlY2V2ZW50K2p3dOKAnSBNSU1FIHR5cGUgaW4gdGhl IFNFVCBkcmFmdCBiZWZvcmUgcHVibGlzaGluZy4gIFNFVHMgY291bGQgdGhlbiBpbmNsdWRlIHRo ZSDigJx0eXDigJ064oCcc2VjZXZlbnQrand04oCdIGhlYWRlciBwYXJhbWV0ZXIgdmFsdWUgdG8g cHJvdmlkZSBleHBsaWNpdCB0eXBpbmcuICBVbmxlc3MgSSBoZWFyIG9iamVjdGlvbnMgc29vbiwg SSB3aWxsIHByb2NlZWQgb24gdGhpcyBiYXNpcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogV2lsbGlhbSBE ZW5uaXNzIFttYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVuZSAz MCwgMjAxNyA5OjMzIEFNDQpUbzogUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KQ2M6IE5hdCBTYWtpbXVyYSA8c2FraW11 cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PjsgRGljayBIYXJkdCA8ZGlj ay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj47IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj47IGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIEhlYWRzLXVwIGFib3V0IFNFVCBzcGVjIHVwZGF0ZXMN Cg0KKzEgdG8gdHlwLg0KDQpTbyAidHlwIjogInNldCIgb3IgInR5cCI6ICJldmVudCI/DQoNCk9u IFRodSwgSnVuIDI5LCAyMDE3IGF0IDU6MTcgUE0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQorMSB0byB0 eXAgY2xhaW0uDQoNClBoaWwNCg0KT24gSnVuIDI5LCAyMDE3LCBhdCA1OjAxIFBNLCBOYXQgU2Fr aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3Jv dGU6DQpTb3JyeSBmb3IgYSB0YXJkeSByZXBseSwgYnV0ICsxIGZvciB0aGUgYm90aCBjaGFuZ2Vz LiAnZXhwJyBjbGFpbSByZXF1aXJlbWVudCBpcyBhIGdvb2QgcHJhY3RpY2FsIHN0ZXAgd2l0aCBh IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuDQpIYXZpbmcgc2FpZCB0aGF0LCBJIGJlbGlldmUgaW5m ZXJyaW5nIG1lc3NhZ2UgdHlwZXMgZnJvbSB0aGUgZXhpc3RlbmNlL2Fic2VuY2Ugb2YgYSBjbGFp bSBpcyBub3QgYSBnb29kIHNlY3VyaXR5IHByYWN0aWNlLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGFu IGV4cGxpY2l0IHR5cGluZyB0aHJvdWdoICJ0eXAiIGNsYWltIGFkZGVkIGFzIHdlbGwuDQoNCk5h dA0KDQpPbiBGcmksIEp1biAzMCwgMjAxNyBhdCA3OjA0IEFNIFBoaWwgSHVudCAoSURNKSA8cGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpP ay4NCg0KSSBzcG9rZSB3aXRoIE1pa2UgYW5kIGhlIHdpbGwgcG9zdCBoaXMgY2hhbmdlcyB0byBT RVQgaW4gYSBuZXcgcmV2aXNpb24gb3ZlciB0aGUgd2Vla2VuZC4NCg0KUGhpbA0KDQpPbiBKdW4g MjksIDIwMTcsIGF0IDE6NTEgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KSSB1bmRlcnN0YW5kIGl0IGlzIG5l dyBhbmQgdGhhdCB0aGVyZSBpcyBjb250ZW50aW9uLg0KDQpXZSBjbGVhcmx5IHdhbnQgY29uc2Vu c3VzIGZvciB1cyB0byBiZSBkb25lIHdpdGggdGhlIGRyYWZ0LiBJIHRoaW5rIGhhdmluZyBpdCBp biB0aGUgbmV4dCBkcmFmdCBhbmNob3JzIHRoZSBkaXNjdXNzaW9uIHNvIHdlIGNhbiBkaXNjdXNz IGFuZCBhcnJpdmUgYXQgY29uc2Vuc3VzIG9yIGFuIGFsdGVybmF0aXZlLg0KDQpTbyB5ZXMsIGlz IGxpa2UgYSBuZXcgZHJhZnQgcG9zdGVkIHNvIHdlIGNhbiBkaXNjdXNzLg0KDQpPbiBUaHUsIEp1 biAyOSwgMjAxNyBhdCAxMjo1OCBQTSBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KRGljaywNCg0KVGhlIHNlY3Rpb24g aXMgYSBicmFuZCBuZXcgc2VjdGlvbi4gSXQgc2VlbXMgdG8gbWUgdGhhdCBoYXMgbm90IGJlZW4g YW55IChvciBsaW1pdGVkKSBkaXNjdXNzaW9uIHRvIHdhcnJhbnQgcHV0dGluZyBpdCBpbiB0aGUg ZG9jdW1lbnQuICBJdCBjZXJ0YWlubHkgY2FtZSB0byBtZSBhcyBhIHN1cnByaXNlLg0KDQpJIHRo aW5rIHRoZSBpc3N1ZSBvZiB0cnVzdCBtb2RlbCBuZWVkcyB0byBiZSBkaXNjdXNzZWQuICBJdCBt YXkgbm90IGJlbG9uZyBoZXJlIGF0IGFsbC4NCg0KUGxlYXNlIGFkdmlzZS4gIERvIHlvdSB3YW50 IGl0IHBvc3RlZCBpbiBzcGl0ZSBvZiBjb25zZW5zdXM/DQoNClBoaWwNCg0KT3JhY2xlIENvcnBv cmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QgJiBTdGFuZGFyZHMNCkBp bmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlkLmNvbSZkPUR3 TUZhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmcj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJm09RHpodl8xYVRBaHpzeVFx MVVwQ083cWlXeHpBSEpYOHktX1ZHSkMzRUFDZyZzPWZFVnZGc0Vxa1RtQ3BZNnNJYV9HVl9TM0d5 MWd4aEc1NldhYncyNEcwTEEmZT0+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+DQoNCk9uIEp1biAyOSwgMjAxNywgYXQgMTI6MjUgUE0sIERpY2sgSGFy ZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdy b3RlOg0KDQpIaSBQaGlsDQoNCndydCBhc2tpbmcgZm9yIG1vcmUgZGlzY3Vzc2lvbiwgSSBhcHBy ZWNpYXRlIHlvdSBtYWtpbmcgdGhlIHN1Z2dlc3Rpb24gb24gYmVoYWxmIG9mIHRoZSBjaGFpcnMu IEl0IGRvZXMgc2VlbSB0aGVyZSBpcyBhIHJlYXNvbmFibGUgYW1vdW50IG9mIGRpc2N1c3Npb24g Z29pbmcgb24gbm93IHdvdWxkIHlvdSBub3QgYWdyZWU/DQoNCkknZCBsaWtlIHRvIGdldCB0aGUg ZG9jIHVwZGF0ZWQgaW4gdGltZSBmb3IgUHJhZ3VlIHNvIHRoYXQgd2UgaGF2ZSBhIGNsZWFyIHJl ZmVyZW5jZSBwb2ludCBmb3IgZGlzY3Vzc2lvbiB0aGVyZSBhbmQgdGhlbi4NCg0KVW5jbGVhciB3 aHkgeW91IHdvdWxkIHBvc3QgYSBjaGFuZ2Ugd2hlbiBpdCB3YXMgTWlrZSB0aGF0IGRpZCB0aGlz IHdvcmsuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCk1pa2U6IHdvdWxkIHlvdSB1cGRhdGUg dGhlIGRvYyB3aXRoIHdoYXQgeW91IHRoaW5rIGlzIHJvdWdoIGNvbnNlbnN1cyB3aGVuIHlvdSBo YXZlIHRpbWUgc28gdGhhdCB3ZSBjYW4gaGF2ZSBhIGNyaXNwIGRpc2N1c3Npb24gaW4gUHJhZ3Vl Pw0KDQoNCg0KT24gV2VkLCBKdW4gMjgsIDIwMTcgYXQgNTozOCBQTSwgUGhpbCBIdW50IChJRE0p IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90 ZToNCkkgYWdyZWUgb24gdGhlIGV4cCBwYXJ0Lg0KDQpSZWdhcmRpbmcgdGhlIHNlY29uZCBwYXJ0 LiBJIHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgZGlzY3Vzc2lvbi4NCg0KRm9yIGV4YW1wbGUsIGlu IHRoZSB0aGUgdXNlIGNhc2VzLCB0aGVyZSBtYXkgYmUgY29tcGF0aWJpbGl0eSBpc3N1ZXMgaWYg ZGlmZmVyZW50IHNldCBwcm9maWxlcyBjYW5ub3QgYmUgc2VudCBvdmVyIHRoZSBzYW1lIHN0cmVh bS4NCg0KU3VjaCBwcm9maWxlcyBzaG91bGQgYXZvaWQgdGhpbmdzIGxpa2UgcmVxdWlyaW5nIHNp Z25pbmcgYW5kIGVuY3J5cHRpb24gd2l0aG91dCBjb25zaWRlcmF0aW9uIHJlZ2FyZGluZyBob3cg dGhleSBhcmUgdHJhbnNmZXJyZWQuICBBbHNvIGtleSBtYW5hZ2VtZW50IG1pZ2h0IGJlIGJldHRl ciB0aWVkIHVwIGluIGhvdyB0aGUgc3RyZWFtcyBhcmUgbWFuYWdlcyBiZWNhdXNlIHRoZSBuZXR3 b3JrIHJlbGF0aW9uc2hpcCBtYXkgZGVmaW5lIHRoZSByZXF1aXJlbWVudHMgcmF0aGVyIHRoYW4g dGhlIGRhdGEuDQoNCk15IGluaXRpYWwgcmVhY3Rpb24gaXMsIHRoZSBwcm9maWxlcyBzaG91bGQg c3RpY2sgdG8gdGhlIGRhdGEgYW5kIHZhbGlkIGludGVycHJldGF0aW9uLg0KDQpJZiB0aGUgZ3Jv dXAgYWdyZWVzIEkgd2lsbCBtZXJnZSB0aGUgZXhwIGFuZCBwb3N0IG92ZXIgdGhlIHdlZWtlbmQu DQoNCkkgY2FuIG1lcmdlIHRoZSBzZWNvbmQgcGFydCBpZiB0aGVyZSBpcyBhIHN0cm9uZyBhZ3Jl ZW1lbnQgdG8gZG8gc28uDQoNClRoYW5rcyENCg0KUGhpbA0KDQpPbiBKdW4gMjgsIDIwMTcsIGF0 IDU6MjQgUE0sIFdpbGxpYW0gRGVubmlzcyA8d2Rlbm5pc3NAZ29vZ2xlLmNvbTxtYWlsdG86d2Rl bm5pc3NAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IE1pa2UgZm9yIHdvcmtpbmcgb24g dGhpcy4gSSdtIHZlcnkgaGFwcHkgd2l0aCB0aGUgY2hhbmdlIHJlZ2FyZGluZyB0aGUgImV4cCIg Y2xhaW0sIGFuZCBiZWxpZXZlIGl0IGlzIHRoZSBiZXN0IHJlc29sdXRpb24gdG8gdGhlICJJRCBU b2tlbiIgY29uZnVzaW9uIGNvbmNlcm4uDQoNCkJ5IG1ha2luZyB0aGUgImV4cCIgY2xhaW0gdGhh dCBpcyBhbHJlYWR5PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRHRv a2VuLTJEMDEtMjNzZWN0aW9uLTJEMi4xJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smbT1fWEY5OTR6Vm4xX0FlUy1DelN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgw JnM9NUw5cXFIX2V2a2xYLUhqREY4S2taMmU1Yk5hNmZaYzNrSklYTDJxZlVXcyZlPT4gTk9UIFJF Q09NTUVOREVEIGluIHRoZSBjdXJyZW50IGRyYWZ0IGEgTVVTVCBOT1QsIHdlIGNhbiBwcm92aWRl IHRoZSBJRCBUb2tlbnMgYW5kIFNFVCB1bmlxdWVuZXNzIGd1YXJhbnRlZSB0aGF0IGlzIGRlc2ly ZWQsIGFsbG93aW5nIHRoZXNlIHR3byB0eXBlcyBvZiBKV1RzIHRvIGJlIHVzZWQgd2l0aCBhIGNv bW1vbiBpc3N1ZXIuIFRoaXMgYWxzbyBhbGxvd3MgInN1YiIgdG8gYmUgdXNlZCBmb3IgaXRzIGlu dGVuZGVkIHB1cnBvc2UgKGFzIGRlZmluZWQgYnkgUkZDNzUxOSkgd2l0aG91dCBtb2RpZmljYXRp b24sIHdoaWNoIG90aGVyIHdvcmtpbmcgZ3JvdXBzIHRoYXQgd2lzaCB0byBwcm9maWxlIFNFVCBo YXZlIGV4cHJlc3NlZCBhbiBpbnRlcmVzdCB0byBkbw0KDQpUaGUgYmVuZWZpdCB0aGUgY29tbXVu aXR5IHdpbGwgZ2FpbiBmcm9tIHRoZSBTRVQgc3RhbmRhcmQgb3ZlcmFsbCBpcyBhIHN0YW5kYXJk IHdheSB0byBleHByZXNzIGV2ZW50cyB0aGF0IHdvbid0IGNvbmZsaWN0IHdpdGggSUQgVG9rZW4g KG5vICJpc3MiIHBhcnRpdGlvbmluZyByZXF1aXJlZCkuIFdpdGggTWlrZSdzIGNoYW5nZXMgd2Ug YWNoaWV2ZSB0aGF0LCBhbmQgaW4gYSB3YXkgdGhhdCByZXRhaW5zIHRoZSBvcmlnaW5hbCBzaW1w bGljaXR5LCBleHRlbnNpYmlsaXR5IGFuZCBnZW5lcmFsaXphYmlsaXR5IGdvYWxzIG9mIFNFVCBi eSBub3QgcmVkZWZpbmluZyBhbnkgb2YgSldUJ3Mgc3RhbmRhcmQgY2xhaW1zLg0KDQoNCk9uIFdl ZCwgSnVuIDI4LCAyMDE3IGF0IDU6MDggUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpI aSBmb2xrcywNCg0KSSB3YW50ZWQgdG8gZ2l2ZSB5b3UgYSBoZWFkcy11cCBhYm91dCB0d28gU0VU IHNwZWMgdXBkYXRlcyBpbiB0aGUgY3VycmVudCBlZGl0b3LigJlzIGRyYWZ0IGJlZm9yZSB0aGV5 IGFyZSBwdWJsaXNoZWQuDQoNClRoZSBmaXJzdCBzb2x2ZXMgdGhlIHBvdGVudGlhbCBJRCBUb2tl biAvIFNFVCBjb25mdXNpb24gcHJvYmxlbSBieSByZXF1aXJpbmcgdGhhdCBTRVRzIG5vdCBpbmNs dWRlIGEgdG9wLWxldmVsIOKAnGV4cOKAnSBjbGFpbSB3aGVuIElEIFRva2VucyBjb3VsZCBhbHNv IGJlIGdlbmVyYXRlZCBieSB0aGUgc2FtZSBpc3N1ZXIuICBCZWNhdXNlIOKAnGV4cOKAnSBpcyBh IHJlcXVpcmVkIElEIFRva2VuIGNsYWltLCBTRVRzIHdvdWxkIHRoZXJlZm9yZSBiZSByZWplY3Rl ZCBieSBleGlzdGluZyBJRCBUb2tlbiB2YWxpZGF0aW9uIGNvZGUuICBOb3RlIHRoYXQgdGhpcyBz b2x1dGlvbiBpcyBhbHJlYWR5IHJlY29tbWVuZGVkIGluIHRoZSBzcGVjaWZpY2F0aW9uLiAgVGhl IGVkaXRvcuKAmXMgZHJhZnQgdXBkYXRlIG1ha2VzIHRoaXMgc29sdXRpb24gbWFuZGF0b3J5LiAg VGhpcyBwcm92aWRlcyBhIHNpbXBsZSBhbmQgZHVyYWJsZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxl bSB3ZSBhZ3JlZWQgdG8gc29sdmUgYXQgSUVURiA5OCBpbiBDaGljYWdvIGFuZCB0aGF0IGhhcyBi ZWVuIHRoZSBzdWJqZWN0IG9mIG11Y2ggZGlzY3Vzc2lvbiBzaW5jZS4NCg0KVGhlIHNlY29uZCBh ZGRzIHRoZSBmb2xsb3dpbmcgbmV3IHNlY3Rpb246DQoNClJlcXVpcmVtZW50cyBmb3IgU0VUIFBy b2ZpbGVzDQoNClByb2ZpbGUgU3BlY2lmaWNhdGlvbnMgZm9yIFNFVHMgZGVmaW5lIHRoZSBzeW50 YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIGNvbmZvcm1pbmcgdG8gdGhhdCBTRVQgcHJvZmlsZSBh bmQgcnVsZXMgZm9yIHZhbGlkYXRpbmcgdGhvc2UgU0VUcy4gVGhlIHN5bnRheCBkZWZpbmVkIGJ5 IHByb2ZpbGluZyBzcGVjaWZpY2F0aW9ucyBpbmNsdWRlcyB3aGF0IGNsYWltcyBhbmQgZXZlbnQg cGF5bG9hZCB2YWx1ZXMgYXJlIHVzZWQgYnkgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUuDQoN CkRlZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFNFVCBjb250ZW50cyBmb3IgU0VUcyB1dGls aXppbmcgdGhlIHByb2ZpbGUgaXMgZXF1YWxseSBpbXBvcnRhbnQuIFBvc3NpYmx5IG1vc3QgaW1w b3J0YW50IGlzIGRlZmluaW5nIHRoZSBwcm9jZWR1cmVzIHVzZWQgdG8gdmFsaWRhdGUgdGhlIFNF VCBpc3N1ZXIgYW5kIHRvIG9idGFpbiB0aGUga2V5cyBjb250cm9sbGVkIGJ5IHRoZSBpc3N1ZXIg dGhhdCB3ZXJlIHVzZWQgZm9yIGNyeXB0b2dyYXBoaWMgb3BlcmF0aW9ucyB1c2VkIGluIHRoZSBK V1QgcmVwcmVzZW50aW5nIHRoZSBTRVQuIEZvciBpbnN0YW5jZSwgc29tZSBwcm9maWxlcyBtYXkg ZGVmaW5lIGFuIGFsZ29yaXRobSBmb3IgcmV0cmlldmluZyB0aGUgU0VUIGlzc3VlcidzIGtleXMg dGhhdCB1c2VzIHRoZSBpc3MgY2xhaW0gdmFsdWUgYXMgaXRzIGlucHV0Lg0KDQpQcm9maWxlIFNw ZWNpZmljYXRpb25zIE1VU1QgY2xlYXJseSBzcGVjaWZ5IHRoZSBzdGVwcyB0aGF0IGEgcmVjaXBp ZW50IG9mIGEgU0VUIHV0aWxpemluZyB0aGF0IHByb2ZpbGUgTVVTVCBwZXJmb3JtIHRvIHZhbGlk YXRlIHRoYXQgdGhlIFNFVCBpcyBib3RoIHN5bnRhY3RpY2FsbHkgYW5kIHNlbWFudGljYWxseSB2 YWxpZC4NCg0KSXTigJlzIGluY2x1ZGVkIHRvIGluZm9ybSBwcm9maWxlIHdyaXRlcnMgYWJvdXQg d2hhdCB0aGV5IG11c3QgZG8gdG8gYmUgYWJsZSB0byB1c2UgU0VUcyBzZWN1cmVseS4gIFdoaWxl IG11Y2ggb2YgdGhlIGRpc2N1c3Npb24gYXMgb2YgbGF0ZSBoYXMgYmVlbiBhYm91dCBzeW50YXgs IHNlbWFudGljcyBpcyBlcXVhbGx5IGltcG9ydGFudCwgYW5kIG11c3QgYmUgY29uc2lkZXJlZCBi eSBwcm9maWxlIHdyaXRlcnMgYW5kIGRlcGxveWVycy4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIG5l dyBzZWN0aW9uIGNvbnRhaW5zIG9ubHkgc3RhdGVtZW50cyB0aGF0IGFyZSBhbHJlYWR5IGZhY3R1 YWxseSBhY2N1cmF0ZSByZXF1aXJlbWVudHMgYnV0IHRoYXQgd2VyZSBwcmV2aW91c2x5IHVuc3Rh dGVkLiAgVGhlIGVkaXRvcuKAmXMgZHJhZnQgbWFrZXMgdGhlc2UgcmVxdWlyZW1lbnRzIGV4cGxp Y2l0LiAgRmVlZGJhY2sgb24gaG93IHRvIG1ha2UgdGhlc2UgcmVxdWlyZW1lbnRzIGV2ZW4gbW9y ZSBjbGVhciwgaXMgb2YgY291cnNlLCB3ZWxjb21lZC4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZtPV9YRjk5NHpW bjFfQWVTLUN6U3RxT1FhVlFwc2RqanZmQnkzNVMwbzd0SDAmcz0zczFHQ2MtM2cyS1VfcE42SHZX VkhnV0JKWHM2T0dQWThLLW5GYXFVeEtRJmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGll dGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2 ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksx MCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1FVGJHSXhS WkxjUWZZWnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdRJnM9bE1Tb3diRG5qVWVYRTd6THBy R0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZlPT4NCg0KDQoNCi0tDQpTdWJzY3JpYmUgdG8gdGhl IEhBUkRUV0FSRTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cC0zQV9faGFyZHR3YXJlLmNvbV8mZD1Ed01GYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hC S0NYNVlUcGtLWTA1N1NiSzEwJnI9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0 Q19sTElHayZtPUVUYkdJeFJaTGNRZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9YR1Emcz0z VWQxdjJwR1hEdzQ1ZzlGa21Jd3RXbzQ1emRGR19OU2djamNmNmtIbkV3JmU9PiBtYWlsIGxpc3Qg dG8gbGVhcm4gYWJvdXQgcHJvamVjdHMgSSBhbSB3b3JraW5nIG9uIQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0K SWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ UWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3ds TktlNENfbExJR2smbT1FVGJHSXhSWkxjUWZZWnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdR JnM9bE1Tb3diRG5qVWVYRTd6THByR0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZlPQ0KDQotLQ0K U3Vic2NyaWJlIHRvIHRoZSBIQVJEVFdBUkU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHAtM0FfX2hhcmR0d2FyZS5jb21fJmQ9RHdNRmFRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNl R0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1Eemh2XzFhVEFoenN5UXExVXBDTzdxaVd4ekFISlg4 eS1fVkdKQzNFQUNnJnM9Zks4UlhuMDFhaXhvWXNDbGtrdWRnSkdFeEgwZGR2NkN2M0tYRlk0UHRD MCZlPT4gbWFpbCBsaXN0IHRvIGxlYXJuIGFib3V0IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiEN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVu dCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smbT1sRmk5eDNYemhCMU9Id2hWbm1IMmFyaWRXMS13MVRUY0hCMkht ZWtjcmpNJnM9bGQwbGk0ZHFhajZTOG11R3N4cEJjSEJjWTFQbHlMQkxKLVRjeUVycXowOCZlPT4N Ci0tDQoNCk5hdCBTYWtpbXVyYQ0KDQpDaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBGb3Vu ZGF0aW9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZl bnQNCg0KDQo= --_000_CY4PR21MB0504BE96F3888DE13F528EC1F5D30CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5tLTU5MDIw MjcyNTMxMDgyMTg4NzZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV8t NTkwMjAyNzI1MzEwODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLm0tNTkwMjAy NzI1MzEwODIxODg3Nm0yMDkyNzAzODA3MDkzMDY0NTEwaG9lbnpiDQoJe21zby1zdHlsZS1uYW1l Om1fLTU5MDIwMjcyNTMxMDgyMTg4NzZtMjA5MjcwMzgwNzA5MzA2NDUxMGhvZW56Yjt9DQpzcGFu LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlllczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gV2lsbGlhbSBEZW5uaXNzIFttYWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbV0g PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAzMCwgMjAxNyAyOjA4IFBNPGJyPg0KPGI+ VG86PC9iPiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBQaGls IEh1bnQgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OzsgTmF0IFNha2ltdXJhICZsdDtzYWtp bXVyYUBnbWFpbC5jb20mZ3Q7OyBpZC1ldmVudEBpZXRmLm9yZzsgRGljayBIYXJkdCAmbHQ7ZGlj ay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRd IEhlYWRzLXVwIGFib3V0IFNFVCBzcGVjIHVwZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPklzIGFwcGxpY2F0aW9uL3NlY2V2 ZW50JiM0Mztqd3QgdGhpcyBmb2xsb3dpbmcgdGhlIFJGQzMwMjMgcGF0dGVybj8gaS5lLiBpbmRp Y2F0aW5nIHRoYXQgaXQncyBhIHNlY2V2ZW50IHByaW1hcmlseSwgYnV0IGFsc28gYSBKV1Q/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJp LCBKdW4gMzAsIDIwMTcgYXQgMjowNSBQTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Vbmxlc3MgdGhlcmXigJlzIGFuIGVuY29kaW5nIGZvciBzZWN1cml0eSBldmVu dHMgb3RoZXIgdGhhbiBKV1QsIHdvdWxkbuKAmXQgYXBwbGljYXRpb24vc2VjZXZlbnQgc3VmZmlj ZT88c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBKdW4gMzAsIDIwMTcsIGF0IDEyOjU2IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVm PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPlRoZXJlIGhhZCBhbHJlYWR5IGJlZW4gZGlzY3Vzc2lvbnMsIGJvdGggaW4gQ2hpY2Fn bywgYW5kIGluIHRoZSBKV1QgQkNQIGNvbnRleHQsIHRoYXQgaWYgd2Ugd2VyZSBnb2luZyB0byB1 c2UgYSB0eXBlIGlkZW50aWZpZXIsIHdlIHdvdWxkIHVzZSB0aGUgZXhpc3Rpbmcg4oCcdHlw4oCd IGhlYWRlciBwYXJhbWV0ZXIgYW5kIG5vdCBjcmVhdGUgYSBuZXcgY2xhaW0uJm5ic3A7IFRoaXMN CiBpcyBhIE1JTUUgdHlwZSwgd2l0aCB0aGUgYWJpbGl0eSB0byBvbWl0IOKAnGFwcGxpY2F0aW9u L+KAnSBmb3Igc3BhY2UgcmVhc29ucywgaWYgZGVzaXJlZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlNpbmNlIHRoZXJl IGFwcGVhcnMgdG8gYmUgYnJvYWQgaW50ZXJlc3QgaW4gaGF2aW5nIHRoZSBhYmlsaXR5IHRvIHVz ZSBleHBsaWNpdCB0eXBpbmcgb2YgdGhlIFNFVCwgSSB3aWxsIHBsYW4gdG8gZGVmaW5lIHRoZSDi gJxhcHBsaWNhdGlvbi9zZWNldmVudCYjNDM7and04oCdIE1JTUUgdHlwZSBpbiB0aGUgU0VUIGRy YWZ0IGJlZm9yZSBwdWJsaXNoaW5nLiZuYnNwOyBTRVRzIGNvdWxkDQogdGhlbiBpbmNsdWRlIHRo ZSDigJx0eXDigJ064oCcc2VjZXZlbnQmIzQzO2p3dOKAnSBoZWFkZXIgcGFyYW1ldGVyIHZhbHVl IHRvIHByb3ZpZGUgZXhwbGljaXQgdHlwaW5nLiZuYnNwOyBVbmxlc3MgSSBoZWFyIG9iamVjdGlv bnMgc29vbiwgSSB3aWxsIHByb2NlZWQgb24gdGhpcyBiYXNpcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0ibV8tNTkw MjAyNzI1MzEwODIxODg3Nl9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9Im0tNTkwMjAyNzI1MzEw ODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldpbGxpYW0gRGVubmlz cyBbPGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86d2Rlbm5pc3NAZ29vZ2xlLmNvbTwvYT5dPHNwYW4gY2xhc3M9Im0tNTkwMjAyNzI1MzEw ODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6 PC9iPjxzcGFuIGNsYXNzPSJtLTU5MDIwMjcyNTMxMDgyMTg4NzZhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXksIEp1bmUgMzAsIDIwMTcgOTozMyBBTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0ibS01OTAyMDI3MjUzMTA4MjE4ODc2YXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtLTU5MDIwMjcyNTMxMDgyMTg4NzZh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OYXQgU2FraW11cmEgJmx0OzxhIGhy ZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBn bWFpbC5jb208L2E+Jmd0OzsgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0 OzsNCiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDs7DQo8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p ZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0ibS01 OTAyMDI3MjUzMTA4MjE4ODc2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtJZC1ldmVudF0gSGVhZHMtdXAgYWJvdXQgU0VUIHNwZWMgdXBkYXRlczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIHRv IHR5cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvICZxdW90O3R5cCZxdW90OzogJnF1b3Q7c2V0JnF1 b3Q7IG9yICZxdW90O3R5cCZxdW90OzogJnF1b3Q7ZXZlbnQmcXVvdDs/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUaHUsIEp1biAyOSwgMjAxNyBhdCA1OjE3IFBNLCBQaGlsIEh1bnQgKElETSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiYjNDM7MSB0byB0eXAgY2xhaW0uJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJtLTU5MDIwMjcyNTMxMDgyMTg4NzZt MjA5MjcwMzgwNzA5MzA2NDUxMGhvZW56YiI+UGhpbDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4gMjksIDIwMTcs IGF0IDU6MDEgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNha2lt dXJhQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSBmb3Ig YSB0YXJkeSByZXBseSwgYnV0Jm5ic3A7JiM0MzsxIGZvciB0aGUgYm90aCBjaGFuZ2VzLiAnZXhw JyBjbGFpbSByZXF1aXJlbWVudCBpcyBhIGdvb2QgcHJhY3RpY2FsIHN0ZXAgd2l0aCBhIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5nIHNhaWQgdGhhdCwgSSBiZWxpZXZlIGlu ZmVycmluZyBtZXNzYWdlIHR5cGVzIGZyb20gdGhlIGV4aXN0ZW5jZS9hYnNlbmNlIG9mIGEgY2xh aW0gaXMgbm90IGEgZ29vZCBzZWN1cml0eSBwcmFjdGljZS4gSSB3b3VsZCBsaWtlIHRvIHNlZSBh biBleHBsaWNpdCB0eXBpbmcgdGhyb3VnaCAmcXVvdDt0eXAmcXVvdDsgY2xhaW0gYWRkZWQgYXMg d2VsbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVuIDMwLCAyMDE3IGF0IDc6MDQgQU0gUGhpbCBIdW50IChJ RE0pICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTU5MDIwMjcyNTMxMDgyMTg4NzZtXzIwOTI3MDM4MDcw OTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0QXBwbGVN YWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy01OTAyMDI3MjUzMTA4MjE4ODc2 bV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYw MjE1ODkwNEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBzcG9rZSB3aXRoIE1pa2UgYW5kIGhlIHdpbGwgcG9zdCBoaXMgY2hhbmdlcyB0byBTRVQgaW4g YSBuZXcgcmV2aXNpb24gb3ZlciB0aGUgd2Vla2VuZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJtXy01OTAyMDI3MjUzMTA4MjE4 ODc2bV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYz NjYwMjE1ODkwNEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tNTkw MjAyNzI1MzEwODIxODg3Nm1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0 MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpPbiBKdW4gMjksIDIwMTcsIGF0IDE6NTEgUE0sIERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRpY2suaGFyZHRAZ21haWwuY29tPC9zcGFuPjwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQgaXQgaXMgbmV3IGFu ZCB0aGF0IHRoZXJlIGlzIGNvbnRlbnRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldlIGNsZWFybHkgd2FudCBjb25zZW5zdXMgZm9yIHVzIHRvIGJlIGRvbmUgd2l0aCB0aGUg ZHJhZnQuIEkgdGhpbmsgaGF2aW5nIGl0IGluIHRoZSBuZXh0IGRyYWZ0IGFuY2hvcnMgdGhlIGRp c2N1c3Npb24gc28gd2UgY2FuIGRpc2N1c3MgYW5kIGFycml2ZSBhdCBjb25zZW5zdXMgb3IgYW4g YWx0ZXJuYXRpdmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHllcywgaXMg bGlrZSBhIG5ldyBkcmFmdCBwb3N0ZWQgc28gd2UgY2FuIGRpc2N1c3MuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUaHUsIEp1biAyOSwgMjAxNyBhdCAxMjo1OCBQTSBQaGlsIEh1bnQgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RGljayw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHNlY3Rpb24gaXMgYSBicmFuZCBuZXcgc2VjdGlvbi4gSXQgc2VlbXMgdG8gbWUgdGhhdCBoYXMg bm90IGJlZW4gYW55IChvciBsaW1pdGVkKSBkaXNjdXNzaW9uIHRvIHdhcnJhbnQgcHV0dGluZyBp dCBpbiB0aGUgZG9jdW1lbnQuJm5ic3A7IEl0IGNlcnRhaW5seSBjYW1lIHRvIG1lIGFzIGEgc3Vy cHJpc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGlzc3VlIG9mIHRy dXN0IG1vZGVsIG5lZWRzIHRvIGJlIGRpc2N1c3NlZC4mbmJzcDsgSXQgbWF5IG5vdCBiZWxvbmcg aGVyZSBhdCBhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBhZHZpc2UuJm5i c3A7IERvIHlvdSB3YW50IGl0IHBvc3RlZCBpbiBzcGl0ZSBvZiBjb25zZW5zdXM/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGhpbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2Vz IEFyY2hpdGVjdCAmYW1wOyBTdGFuZGFyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBpbmRlcGVuZGVudGlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fd3d3LmluZGVwZW5kZW50aWQuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209RHpodl8xYVRBaHpzeVFxMVVwQ083 cWlXeHpBSEpYOHktX1ZHSkMzRUFDZyZhbXA7cz1mRVZ2RnNFcWtUbUNwWTZzSWFfR1ZfUzNHeTFn eGhHNTZXYWJ3MjRHMExBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDI5LCAy MDE3LCBhdCAxMjoyNSBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFy ZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ ZGljay5oYXJkdEBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIFBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndydCBhc2tpbmcgZm9yIG1vcmUg ZGlzY3Vzc2lvbiwgSSBhcHByZWNpYXRlIHlvdSBtYWtpbmcgdGhlIHN1Z2dlc3Rpb24gb24gYmVo YWxmIG9mIHRoZSBjaGFpcnMuIEl0IGRvZXMgc2VlbSB0aGVyZSBpcyBhIHJlYXNvbmFibGUgYW1v dW50IG9mIGRpc2N1c3Npb24gZ29pbmcgb24gbm93IHdvdWxkIHlvdSBub3QgYWdyZWU/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBsaWtlIHRvIGdldCB0aGUgZG9jIHVwZGF0ZWQgaW4g dGltZSBmb3IgUHJhZ3VlIHNvIHRoYXQgd2UgaGF2ZSBhIGNsZWFyIHJlZmVyZW5jZSBwb2ludCBm b3IgZGlzY3Vzc2lvbiB0aGVyZSBhbmQgdGhlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlVuY2xlYXIgd2h5IHlvdSB3b3VsZCBwb3N0IGEgY2hhbmdlIHdoZW4gaXQgd2FzIE1p a2UgdGhhdCBkaWQgdGhpcyB3b3JrLiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NaWtlOiB3b3VsZCB5b3UgdXBkYXRlIHRoZSBkb2Mgd2l0aCB3aGF0 IHlvdSB0aGluayBpcyByb3VnaCBjb25zZW5zdXMgd2hlbiB5b3UgaGF2ZSB0aW1lIHNvIHRoYXQg d2UgY2FuIGhhdmUgYSBjcmlzcCBkaXNjdXNzaW9uIGluIFByYWd1ZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBKdW4gMjgsIDIwMTcgYXQgNTozOCBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFncmVlIG9uIHRoZSBleHAgcGFydC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy01OTAyMDI3MjUzMTA4MjE4ODc2bV8yMDkyNzAzODA3MDkz MDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYx MjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTU5MDIwMjcyNTMxMDgyMTg4NzZtXzIwOTI3MDM4MDcwOTMw NjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEy NzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTczODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBzZWNvbmQgcGFydC4gSSB3 b3VsZCBsaWtlIHRvIHNlZSBtb3JlIGRpc2N1c3Npb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tNTkwMjAyNzI1MzEwODIxODg3Nm1fMjA5MjcwMzgw NzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03 Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJl Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy01OTAyMDI3MjUzMTA4MjE4ODc2bV8yMDkyNzAzODA3 MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcy ODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBsZU1haWxTaWduYXR1cmUi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBpbiB0aGUgdGhlIHVz ZSBjYXNlcywgdGhlcmUgbWF5IGJlIGNvbXBhdGliaWxpdHkgaXNzdWVzIGlmIGRpZmZlcmVudCBz ZXQgcHJvZmlsZXMgY2Fubm90IGJlIHNlbnQgb3ZlciB0aGUgc2FtZSBzdHJlYW0uJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tNTkwMjAyNzI1MzEwODIx ODg3Nm1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4MTU4OTk2 MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTkyMTU5NzM4MjkwQXBw bGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy01OTAyMDI3MjUzMTA4MjE4 ODc2bV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21fNTgxNTg5OTYz NjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3MzgyOTBBcHBs ZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Y2ggcHJvZmls ZXMgc2hvdWxkIGF2b2lkIHRoaW5ncyBsaWtlIHJlcXVpcmluZyBzaWduaW5nIGFuZCBlbmNyeXB0 aW9uIHdpdGhvdXQgY29uc2lkZXJhdGlvbiByZWdhcmRpbmcgaG93IHRoZXkgYXJlIHRyYW5zZmVy cmVkLiZuYnNwOyBBbHNvIGtleSBtYW5hZ2VtZW50IG1pZ2h0IGJlIGJldHRlciB0aWVkIHVwIGlu IGhvdyB0aGUgc3RyZWFtcyBhcmUgbWFuYWdlcyBiZWNhdXNlIHRoZSBuZXR3b3JrIHJlbGF0aW9u c2hpcA0KIG1heSBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyByYXRoZXIgdGhhbiB0aGUgZGF0YS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy01OTAyMDI3 MjUzMTA4MjE4ODc2bV8yMDkyNzAzODA3MDkzMDY0NTEwbV8tMzc5MjI5MTIxMTYwMTM4OTQzN21f NTgxNTg5OTYzNjYwMjE1ODkwNG1fLTcyODYxMjcyNzU3OTgyMDE0Mm1fLTI0Njc5OTkxOTIxNTk3 MzgyOTBBcHBsZU1haWxTaWduYXR1cmUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTU5MDIwMjcy NTMxMDgyMTg4NzZtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81 ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTcz ODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkg aW5pdGlhbCByZWFjdGlvbiBpcywgdGhlIHByb2ZpbGVzIHNob3VsZCBzdGljayB0byB0aGUgZGF0 YSBhbmQgdmFsaWQgaW50ZXJwcmV0YXRpb24uJm5ic3A7PGJyPg0KPGJyPg0KSWYgdGhlIGdyb3Vw IGFncmVlcyBJIHdpbGwgbWVyZ2UgdGhlIGV4cCBhbmQgcG9zdCBvdmVyIHRoZSB3ZWVrZW5kLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTU5MDIwMjcy NTMxMDgyMTg4NzZtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAxMzg5NDM3bV81 ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5OTE5MjE1OTcz ODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tNTkwMjAyNzI1 MzEwODIxODg3Nm1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEzODk0MzdtXzU4 MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5MTkyMTU5NzM4 MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNh biBtZXJnZSB0aGUgc2Vjb25kIHBhcnQgaWYgdGhlcmUgaXMgYSBzdHJvbmcgYWdyZWVtZW50IHRv IGRvIHNvLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f LTU5MDIwMjcyNTMxMDgyMTg4NzZtXzIwOTI3MDM4MDcwOTMwNjQ1MTBtXy0zNzkyMjkxMjExNjAx Mzg5NDM3bV81ODE1ODk5NjM2NjAyMTU4OTA0bV8tNzI4NjEyNzI3NTc5ODIwMTQybV8tMjQ2Nzk5 OTE5MjE1OTczODI5MEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8t NTkwMjAyNzI1MzEwODIxODg3Nm1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEz ODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5 MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8t NTkwMjAyNzI1MzEwODIxODg3Nm1fMjA5MjcwMzgwNzA5MzA2NDUxMG1fLTM3OTIyOTEyMTE2MDEz ODk0MzdtXzU4MTU4OTk2MzY2MDIxNTg5MDRtXy03Mjg2MTI3Mjc1Nzk4MjAxNDJtXy0yNDY3OTk5 MTkyMTU5NzM4MjkwQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpPbiBKdW4gMjgsIDIwMTcsIGF0IDU6MjQgUE0sIFdpbGxpYW0gRGVubmlzcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53ZGVubmlzc0Bnb29nbGUuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgTWlrZSBmb3Igd29ya2luZyBv biB0aGlzLiBJJ20gdmVyeSBoYXBweSB3aXRoIHRoZSBjaGFuZ2UgcmVnYXJkaW5nIHRoZSAmcXVv dDtleHAmcXVvdDsgY2xhaW0sIGFuZCBiZWxpZXZlIGl0IGlzIHRoZSBiZXN0IHJlc29sdXRpb24g dG8gdGhlICZxdW90O0lEIFRva2VuJnF1b3Q7IGNvbmZ1c2lvbiBjb25jZXJuLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CeSBtYWtpbmcgdGhlICZxdW90O2V4cCZxdW90OyBjbGFpbSB0aGF0 IGlzPHNwYW4gY2xhc3M9Im0tNTkwMjAyNzI1MzEwODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRz ZWNldmVudC0yRHRva2VuLTJEMDEtMjNzZWN0aW9uLTJEMi4xJmFtcDtkPUR3TUZhUSZhbXA7Yz1S b1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJy S3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209X1hGOTk0elZuMV9BZVMt Q3pTdHFPUWFWUXBzZGpqdmZCeTM1UzBvN3RIMCZhbXA7cz01TDlxcUhfZXZrbFgtSGpERjhLa1oy ZTViTmE2ZlpjM2tKSVhMMnFmVVdzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmFscmVhZHk8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTU5MDIwMjcy NTMxMDgyMTg4NzZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OT1QNCiBSRUNP TU1FTkRFRCBpbiB0aGUgY3VycmVudCBkcmFmdCBhIE1VU1QgTk9ULCB3ZSBjYW4gcHJvdmlkZSB0 aGUgSUQgVG9rZW5zIGFuZCBTRVQgdW5pcXVlbmVzcyBndWFyYW50ZWUgdGhhdCBpcyBkZXNpcmVk LCBhbGxvd2luZyB0aGVzZSB0d28gdHlwZXMgb2YgSldUcyB0byBiZSB1c2VkIHdpdGggYSBjb21t b24gaXNzdWVyLiBUaGlzIGFsc28gYWxsb3dzICZxdW90O3N1YiZxdW90OyB0byBiZSB1c2VkIGZv ciBpdHMgaW50ZW5kZWQgcHVycG9zZSAoYXMgZGVmaW5lZA0KIGJ5IFJGQzc1MTkpIHdpdGhvdXQg bW9kaWZpY2F0aW9uLCB3aGljaCBvdGhlciB3b3JraW5nIGdyb3VwcyB0aGF0IHdpc2ggdG8gcHJv ZmlsZSBTRVQgaGF2ZSBleHByZXNzZWQgYW4gaW50ZXJlc3QgdG8gZG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGJlbmVmaXQgdGhlIGNvbW11bml0eSB3aWxsIGdhaW4gZnJvbSB0aGUg U0VUIHN0YW5kYXJkIG92ZXJhbGwgaXMgYSBzdGFuZGFyZCB3YXkgdG8gZXhwcmVzcyBldmVudHMg dGhhdCB3b24ndCBjb25mbGljdCB3aXRoIElEIFRva2VuIChubyAmcXVvdDtpc3MmcXVvdDsgcGFy dGl0aW9uaW5nIHJlcXVpcmVkKS4gV2l0aCBNaWtlJ3MgY2hhbmdlcyB3ZSBhY2hpZXZlIHRoYXQs IGFuZCBpbiBhIHdheSB0aGF0IHJldGFpbnMgdGhlDQogb3JpZ2luYWwgc2ltcGxpY2l0eSwgZXh0 ZW5zaWJpbGl0eSBhbmQgZ2VuZXJhbGl6YWJpbGl0eSBnb2FscyBvZiBTRVQgYnkgbm90IHJlZGVm aW5pbmcgYW55IG9mIEpXVCdzIHN0YW5kYXJkIGNsYWltcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biAyOCwgMjAxNyBhdCA1OjA4IFBNLCBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhbnRlZCB0 byBnaXZlIHlvdSBhIGhlYWRzLXVwIGFib3V0IHR3byBTRVQgc3BlYyB1cGRhdGVzIGluIHRoZSBj dXJyZW50IGVkaXRvcuKAmXMgZHJhZnQgYmVmb3JlIHRoZXkgYXJlIHB1Ymxpc2hlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZpcnN0 IHNvbHZlcyB0aGUgcG90ZW50aWFsIElEIFRva2VuIC8gU0VUIGNvbmZ1c2lvbiBwcm9ibGVtIGJ5 IHJlcXVpcmluZyB0aGF0IFNFVHMgbm90IGluY2x1ZGUgYSB0b3AtbGV2ZWwg4oCcZXhw4oCdIGNs YWltIHdoZW4gSUQgVG9rZW5zIGNvdWxkIGFsc28gYmUgZ2VuZXJhdGVkIGJ5IHRoZSBzYW1lIGlz c3Vlci4mbmJzcDsgQmVjYXVzZSDigJxleHDigJ0gaXMgYSByZXF1aXJlZCBJRCBUb2tlbiBjbGFp bSwgU0VUcyB3b3VsZA0KIHRoZXJlZm9yZSBiZSByZWplY3RlZCBieSBleGlzdGluZyBJRCBUb2tl biB2YWxpZGF0aW9uIGNvZGUuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIHNvbHV0aW9uIGlzIGFscmVh ZHkgcmVjb21tZW5kZWQgaW4gdGhlIHNwZWNpZmljYXRpb24uJm5ic3A7IFRoZSBlZGl0b3LigJlz IGRyYWZ0IHVwZGF0ZSBtYWtlcyB0aGlzIHNvbHV0aW9uIG1hbmRhdG9yeS4mbmJzcDsgVGhpcyBw cm92aWRlcyBhIHNpbXBsZSBhbmQgZHVyYWJsZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSB3ZSBh Z3JlZWQNCiB0byBzb2x2ZSBhdCBJRVRGIDk4IGluIENoaWNhZ28gYW5kIHRoYXQgaGFzIGJlZW4g dGhlIHN1YmplY3Qgb2YgbXVjaCBkaXNjdXNzaW9uIHNpbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2Vjb25kIGFkZHMgdGhlIGZv bGxvd2luZyBuZXcgc2VjdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDoyNC4wcHQ7bWFyZ2luLXJpZ2h0OjI0LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5SZXF1aXJlbWVudHMgZm9yIFNFVCBQ cm9maWxlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjQuMHB0O21hcmdpbi1yaWdodDoyNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7bWFyZ2luLXJpZ2h0OjI0LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Qcm9m aWxlIFNwZWNpZmljYXRpb25zIGZvciBTRVRzIGRlZmluZSB0aGUgc3ludGF4IGFuZCBzZW1hbnRp Y3Mgb2YgU0VUcyBjb25mb3JtaW5nIHRvIHRoYXQgU0VUIHByb2ZpbGUgYW5kIHJ1bGVzIGZvciB2 YWxpZGF0aW5nIHRob3NlIFNFVHMuIFRoZSBzeW50YXggZGVmaW5lZCBieQ0KIHByb2ZpbGluZyBz cGVjaWZpY2F0aW9ucyBpbmNsdWRlcyB3aGF0IGNsYWltcyBhbmQgZXZlbnQgcGF5bG9hZCB2YWx1 ZXMgYXJlIHVzZWQgYnkgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7bWFyZ2luLXJp Z2h0OjI0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjI0LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkRlZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2Yg dGhlIFNFVCBjb250ZW50cyBmb3IgU0VUcyB1dGlsaXppbmcgdGhlIHByb2ZpbGUgaXMgZXF1YWxs eSBpbXBvcnRhbnQuIFBvc3NpYmx5IG1vc3QgaW1wb3J0YW50IGlzIGRlZmluaW5nIHRoZSBwcm9j ZWR1cmVzIHVzZWQgdG8gdmFsaWRhdGUNCiB0aGUgU0VUIGlzc3VlciBhbmQgdG8gb2J0YWluIHRo ZSBrZXlzIGNvbnRyb2xsZWQgYnkgdGhlIGlzc3VlciB0aGF0IHdlcmUgdXNlZCBmb3IgY3J5cHRv Z3JhcGhpYyBvcGVyYXRpb25zIHVzZWQgaW4gdGhlIEpXVCByZXByZXNlbnRpbmcgdGhlIFNFVC4g Rm9yIGluc3RhbmNlLCBzb21lIHByb2ZpbGVzIG1heSBkZWZpbmUgYW4gYWxnb3JpdGhtIGZvciBy ZXRyaWV2aW5nIHRoZSBTRVQgaXNzdWVyJ3Mga2V5cyB0aGF0IHVzZXMgdGhlPHNwYW4gY2xhc3M9 Im0tNTkwMjAyNzI1MzEwODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmlzczwvc3Bhbj48c3BhbiBjbGFzcz0ibS01OTAy MDI3MjUzMTA4MjE4ODc2YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPmNs YWltDQogdmFsdWUgYXMgaXRzIGlucHV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0O21hcmdpbi1yaWdodDoyNC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7 bWFyZ2luLXJpZ2h0OjI0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5Qcm9maWxlIFNwZWNpZmljYXRpb25zIE1VU1QgY2xlYXJseSBzcGVjaWZ5 IHRoZSBzdGVwcyB0aGF0IGEgcmVjaXBpZW50IG9mIGEgU0VUIHV0aWxpemluZyB0aGF0IHByb2Zp bGUgTVVTVCBwZXJmb3JtIHRvIHZhbGlkYXRlIHRoYXQgdGhlIFNFVCBpcyBib3RoIHN5bnRhY3Rp Y2FsbHkNCiBhbmQgc2VtYW50aWNhbGx5IHZhbGlkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIGluY2x1ZGVkIHRvIGlu Zm9ybSBwcm9maWxlIHdyaXRlcnMgYWJvdXQgd2hhdCB0aGV5IG11c3QgZG8gdG8gYmUgYWJsZSB0 byB1c2UgU0VUcyBzZWN1cmVseS4mbmJzcDsgV2hpbGUgbXVjaCBvZiB0aGUgZGlzY3Vzc2lvbiBh cyBvZiBsYXRlIGhhcyBiZWVuIGFib3V0IHN5bnRheCwgc2VtYW50aWNzIGlzIGVxdWFsbHkgaW1w b3J0YW50LCBhbmQgbXVzdCBiZSBjb25zaWRlcmVkIGJ5IHByb2ZpbGUgd3JpdGVycyBhbmQNCiBk ZXBsb3llcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgYmVsaWV2ZSB0aGF0IHRoZSBuZXcgc2VjdGlvbiBjb250YWlucyBvbmx5IHN0YXRl bWVudHMgdGhhdCBhcmUgYWxyZWFkeSBmYWN0dWFsbHkgYWNjdXJhdGUgcmVxdWlyZW1lbnRzIGJ1 dCB0aGF0IHdlcmUgcHJldmlvdXNseSB1bnN0YXRlZC4mbmJzcDsgVGhlIGVkaXRvcuKAmXMgZHJh ZnQgbWFrZXMgdGhlc2UgcmVxdWlyZW1lbnRzIGV4cGxpY2l0LiZuYnNwOyBGZWVkYmFjayBvbiBo b3cgdG8gbWFrZSB0aGVzZSByZXF1aXJlbWVudHMNCiBldmVuIG1vcmUgY2xlYXIsIGlzIG9mIGNv dXJzZSwgd2VsY29tZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCZXN0IHdp c2hlcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJL dWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1fWEY5OTR6Vm4xX0FlUy1D elN0cU9RYVZRcHNkamp2ZkJ5MzVTMG83dEgwJmFtcDtzPTNzMUdDYy0zZzJLVV9wTjZIdldWSGdX QkpYczZPR1BZOEstbkZhcVV4S1EmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtk PUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEw JmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209 X1hGOTk0elZuMV9BZVMtQ3pTdHFPUWFWUXBzZGpqdmZCeTM1UzBvN3RIMCZhbXA7cz0zczFHQ2Mt M2cyS1VfcE42SHZXVkhnV0JKWHM2T0dQWThLLW5GYXFVeEtRJmFtcDtlPTwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBr S1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xM SUdrJmFtcDttPUVUYkdJeFJaTGNRZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9YR1EmYW1w O3M9bE1Tb3diRG5qVWVYRTd6THByR0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxzcGFuIGNsYXNzPSJtLTU5MDIwMjcy NTMxMDgyMTg4NzZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YnNjcmliZSB0byB0aGU8c3BhbiBjbGFzcz0i bS01OTAyMDI3MjUzMTA4MjE4ODc2YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX2hhcmR0d2FyZS5jb21fJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smYW1wO209RVRiR0l4UlpMY1FmWVp0WVVWazZUN0hrd1lHZlh4LTAy d3kzcDQ1b1hHUSZhbXA7cz0zVWQxdjJwR1hEdzQ1ZzlGa21Jd3RXbzQ1emRGR19OU2djamNmNmtI bkV3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkhB UkRUV0FSRTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9Im0tNTkwMjAyNzI1MzEwODIxODg3NmFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1haWwNCiBsaXN0IHRvIGxlYXJuIGFib3V0 IHByb2plY3RzIEkgYW0gd29ya2luZyBvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01 YmlSckt1Z0NIMEZrSVRTZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUVUYkdJeFJaTGNR ZlladFlVVms2VDdIa3dZR2ZYeC0wMnd5M3A0NW9YR1EmYW1wO3M9bE1Tb3diRG5qVWVYRTd6THBy R0hTUFJneFpNaEVadUlxVGtMVGZnQk5HRSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQm YW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3 U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZh bXA7bT1FVGJHSXhSWkxjUWZZWnRZVVZrNlQ3SGt3WUdmWHgtMDJ3eTNwNDVvWEdRJmFtcDtzPWxN U293YkRualVlWEU3ekxwckdIU1BSZ3haTWhFWnVJcVRrTFRmZ0JOR0UmYW1wO2U9PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPHNwYW4gY2xhc3M9Im0tNTkwMjAyNzI1MzEw ODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWJzY3JpYmUgdG8gdGhlPHNwYW4gY2xh c3M9Im0tNTkwMjAyNzI1MzEwODIxODg3NmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX19oYXJkdHdhcmUuY29tXyZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2 bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRTZUdK eFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPUR6aHZfMWFUQWh6c3lRcTFVcENPN3FpV3h6QUhK WDh5LV9WR0pDM0VBQ2cmYW1wO3M9Zks4UlhuMDFhaXhvWXNDbGtrdWRnSkdFeEgwZGR2NkN2M0tY Rlk0UHRDMCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5IQVJEVFdBUkU8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJtLTU5MDIwMjcyNTMxMDgyMTg4NzZh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYWlsDQogbGlzdCB0byBsZWFybiBh Ym91dCBwcm9qZWN0cyBJIGFtIHdvcmtpbmcgb24hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bh bj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtLWTA1 N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2sm YW1wO209bEZpOXgzWHpoQjFPSHdoVm5tSDJhcmlkVzEtdzFUVGNIQjJIbWVrY3JqTSZhbXA7cz1s ZDBsaTRkcWFqNlM4bXVHc3hwQmNIQmNZMVBseUxCTEotVGN5RXJxejA4JmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS08c3BhbiBjbGFzcz0ibS01OTAyMDI3MjUzMTA4MjE4ODc2YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk5hdCBTYWtpbXVyYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZv dW5kYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K SWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_CY4PR21MB0504BE96F3888DE13F528EC1F5D30CY4PR21MB0504namp_-- From nobody Fri Jun 30 14:12:01 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F3126DC2 for ; Fri, 30 Jun 2017 14:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frH2AIMqs5C4 for ; Fri, 30 Jun 2017 14:11:56 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96D2129B8D for ; Fri, 30 Jun 2017 14:11:55 -0700 (PDT) X-AuditID: 12074422-6a9ff700000067bb-7b-5956be9af324 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.82.26555.A9EB6595; Fri, 30 Jun 2017 17:11:54 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v5ULBqNS019994; Fri, 30 Jun 2017 17:11:53 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5ULBnXb006607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 17:11:51 -0400 From: Justin Richer Message-Id: <4E552A94-E781-4AC1-9BA9-23CF16F20F4D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB1B9A3F-6768-4723-924C-D498438EC6AC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 17:11:49 -0400 In-Reply-To: Cc: William Denniss , Phil Hunt , Nat Sakimura , "id-event@ietf.org" , Dick Hardt To: Mike Jones References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsUixG6nrjtrX1ikQeMvHovHM4ssOhZ0M1ns nfaJxWLB/EZ2izO3VjBabJrTzO7A5rFz1l12jwWbSj2WLPnJ5NG64y+7x8ent1gCWKO4bFJS czLLUov07RK4MvqumhRsnc9SsXjBTNYGxgcPmbsYOTkkBEwkTkzsYQOxhQQWM0ksWyLcxcgF ZG9klGiZ0MsI4Txkkvg8vZsJpIpNQFVi+poWMJtXwErixPlLYN3MAkkS1yefZeli5ACK60v0 PmcECQsLmEs8nTgHrIQFqPXWh5dgizkFYiWurHvJBDKfWeAqo8TmjRtYQBIiAjoSjy9+g7ro GZvE+muFEJfKStyafYl5AiP/LCTrZiGsgwhrSyxb+JoZwtaU2N+9nAVTXEOi89tE1gWMbKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0TfVyM0v0UlNKNzGCY8NFaQfjxH9ehxgFOBiVeHg3hIRF CrEmlhVX5h5ilORgUhLlXXktNFKILyk/pTIjsTgjvqg0J7X4EKMEB7OSCC/bLqBy3pTEyqrU onyYlDQHi5I4r7hGY4SQQHpiSWp2ampBahFMVoaDQ0mCN2QvUKNgUWp6akVaZk4JQpqJgxNk OA/Q8NMLQIYXFyTmFmemQ+RPMRpzbJrx8xsTx6sJ/78xCbHk5eelSonzXtoDVCoAUppRmgc3 DZTeEt4eNn3FKA70nDDvV5AqHmBqhJv3CmgVE9Aq4RkhIKtKEhFSUg2MVr8L2Z5/m7/8g2Gv eGXi3xWiGRkKH7hPhP9+MvOO4/Rql4z9dZdmvc34Fqwx95N500/VYHWVCaa9d6Waf62fLDL3 6VPHrV6iHzhyRWtOPJhu2SMqLLrbKcdE8iDXpqTjuf07VAWffXHzWPTxAc/njOnNq59szbpY WsM0qTh69rVTfa57vtsKKbEUZyQaajEXFScCAKee/E9KAwAA Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:12:00 -0000 --Apple-Mail=_FB1B9A3F-6768-4723-924C-D498438EC6AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eugh. =E2=80=94 Justin > On Jun 30, 2017, at 5:07 PM, Mike Jones = wrote: >=20 > There may be a SAML encoding in the works. > =20 > -- = Mike > =20 > From: Justin Richer [mailto:jricher@mit.edu]=20 > Sent: Friday, June 30, 2017 2:05 PM > To: Mike Jones > Cc: William Denniss ; Phil Hunt = ; Nat Sakimura ; = id-event@ietf.org; Dick Hardt > Subject: Re: [Id-event] Heads-up about SET spec updates > =20 > Unless there=E2=80=99s an encoding for security events other than JWT, = wouldn=E2=80=99t application/secevent suffice? > =20 > =E2=80=94 Justin > =20 > On Jun 30, 2017, at 12:56 PM, Mike Jones > wrote: > =20 > There had already been discussions, both in Chicago, and in the JWT = BCP context, that if we were going to use a type identifier, we would = use the existing =E2=80=9Ctyp=E2=80=9D header parameter and not create a = new claim. This is a MIME type, with the ability to omit = =E2=80=9Capplication/=E2=80=9D for space reasons, if desired. > =20 > Since there appears to be broad interest in having the ability to use = explicit typing of the SET, I will plan to define the = =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the SET draft = before publishing. SETs could then include the = =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2=80=9D header parameter = value to provide explicit typing. Unless I hear objections soon, I will = proceed on this basis. > =20 > -- Mike > =C2=A0 <> > From: William Denniss [mailto:wdenniss@google.com = ]=20 > Sent: Friday, June 30, 2017 9:33 AM > To: Phil Hunt (IDM) > > Cc: Nat Sakimura >; = Dick Hardt >; Mike = Jones >; id-event@ietf.org = > Subject: Re: [Id-event] Heads-up about SET spec updates > =20 > +1 to typ. > =20 > So "typ": "set" or "typ": "event"? > =20 > On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) > wrote: > +1 to typ claim.=20 >=20 > Phil >=20 > On Jun 29, 2017, at 5:01 PM, Nat Sakimura > wrote: >=20 > Sorry for a tardy reply, but +1 for the both changes. 'exp' claim = requirement is a good practical step with a backward compatibility.=20 > Having said that, I believe inferring message types from the = existence/absence of a claim is not a good security practice. I would = like to see an explicit typing through "typ" claim added as well.=20 > =20 > Nat > =20 > On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) > wrote: > Ok.=20 > =20 > I spoke with Mike and he will post his changes to SET in a new = revision over the weekend.=20 > =20 > Phil >=20 > On Jun 29, 2017, at 1:51 PM, Dick Hardt > wrote: >=20 > I understand it is new and that there is contention.=20 > =20 > We clearly want consensus for us to be done with the draft. I think = having it in the next draft anchors the discussion so we can discuss and = arrive at consensus or an alternative.=20 > =20 > So yes, is like a new draft posted so we can discuss.=20 > =20 > On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt > wrote: > Dick, > =20 > The section is a brand new section. It seems to me that has not been = any (or limited) discussion to warrant putting it in the document. It = certainly came to me as a surprise. > =20 > I think the issue of trust model needs to be discussed. It may not = belong here at all. > =20 > Please advise. Do you want it posted in spite of consensus? > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com = > phil.hunt@oracle.com > =20 > On Jun 29, 2017, at 12:25 PM, Dick Hardt > wrote: > =20 > Hi Phil > =20 > wrt asking for more discussion, I appreciate you making the suggestion = on behalf of the chairs. It does seem there is a reasonable amount of = discussion going on now would you not agree? > =20 > I'd like to get the doc updated in time for Prague so that we have a = clear reference point for discussion there and then. > =20 > Unclear why you would post a change when it was Mike that did this = work. Am I missing something? > =20 > Mike: would you update the doc with what you think is rough consensus = when you have time so that we can have a crisp discussion in Prague? > =20 > =20 > =20 > On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) > wrote: > I agree on the exp part.=20 > =20 > Regarding the second part. I would like to see more discussion.=20 > =20 > For example, in the the use cases, there may be compatibility issues = if different set profiles cannot be sent over the same stream.=20 > =20 > Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred. = Also key management might be better tied up in how the streams are = manages because the network relationship may define the requirements = rather than the data.=20 > =20 > My initial reaction is, the profiles should stick to the data and = valid interpretation.=20 >=20 > If the group agrees I will merge the exp and post over the weekend.=20 > =20 > I can merge the second part if there is a strong agreement to do so.=20= > =20 > Thanks! >=20 > Phil >=20 > On Jun 28, 2017, at 5:24 PM, William Denniss > wrote: >=20 > Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. > =20 > By making the "exp" claim that is already = NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to do > =20 > The benefit the community will gain from the SET standard overall is a = standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. > =20 > =20 > On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: > Hi folks, > =20 > I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. > =20 > The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. > =20 > The second adds the following new section: > =20 > Requirements for SET Profiles > =20 > Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. > =20 > Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. > =20 > Profile Specifications MUST clearly specify the steps that a recipient = of a SET utilizing that profile MUST perform to validate that the SET is = both syntactically and semantically valid. > =20 > It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. > =20 > I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. > =20 > Best = wishes, > -- = Mike > =20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D = >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = >=20 >=20 > =20 > --=20 > Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZt= YUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBN= GE&e=3D = > =20 > --=20 > Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = > --=20 > Nat Sakimura > Chairman of the Board, OpenID Foundation > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_FB1B9A3F-6768-4723-924C-D498438EC6AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Eugh.

 =E2=80=94 Justin

On = Jun 30, 2017, at 5:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

There may = be a SAML encoding in the works.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Justin Richer [mailto:jricher@mit.edu] 
Sent: Friday, June 30, 2017 2:05 = PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; Phil Hunt <phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com>; = id-event@ietf.org; = Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Id-event] Heads-up = about SET spec updates
 
Unless there=E2=80=99s an encoding for = security events other than JWT, wouldn=E2=80=99t application/secevent = suffice?
 
 =E2=80=94 Justin
 
On Jun 30, 2017, at 12:56 = PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
There had already been discussions, both in Chicago, and in = the JWT BCP context, that if we were going to use a type identifier, we = would use the existing =E2=80=9Ctyp=E2=80=9D header parameter and not = create a new claim.  This is a MIME type, with the ability to omit = =E2=80=9Capplication/=E2=80=9D for space reasons, if desired.
 
Since there appears to be broad interest in = having the ability to use explicit typing of the SET, I will plan to = define the =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the = SET draft before publishing.  SETs could then include the = =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2=80=9D header parameter = value to provide explicit typing.  Unless I hear objections soon, I = will proceed on this basis.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
From: William Denniss [mailto:wdenniss@google.com] 
Sent: Friday, June 30, 2017 9:33 = AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Nat Sakimura <sakimura@gmail.com>; Dick = Hardt <dick.hardt@gmail.com>; Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Heads-up = about SET spec updates
 
+1 to typ.
 
So "typ": "set" or "typ": "event"?
 
On Thu, Jun 29, 2017 at 5:17 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> = wrote:
+1 to typ claim. 

Phil


On = Jun 29, 2017, at 5:01 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Sorry for a tardy reply, = but +1 for the both changes. 'exp' claim requirement is a good = practical step with a backward compatibility. 
Having said that, I believe inferring = message types from the existence/absence of a claim is not a good = security practice. I would like to see an explicit typing through "typ" = claim added as well. 
 
Nat
 
On Fri, Jun 30, 2017 at = 7:04 AM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Ok. 
 
I= spoke with Mike and he will post his changes to SET in a new revision = over the weekend. 
 
Phil


On Jun 29, 2017, at 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I = understand it is new and that there is contention. 
 
We clearly want consensus for us to be = done with the draft. I think having it in the next draft anchors the = discussion so we can discuss and arrive at consensus or an = alternative. 
 
So yes, is like a new draft posted so = we can discuss. 
 
On Thu, Jun 29, 2017 at = 12:58 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Dick,
 
The section is a brand new section. It = seems to me that has not been any (or limited) discussion to warrant = putting it in the document.  It certainly came to me as a = surprise.
 
I think the issue of trust model needs = to be discussed.  It may not belong here at all.
 
Please advise.  Do you want it = posted in spite of consensus?
 
Phil
 
Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Jun = 29, 2017, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
 
Hi Phil
 
wrt asking for more discussion, I = appreciate you making the suggestion on behalf of the chairs. It does = seem there is a reasonable amount of discussion going on now would you = not agree?
 
I'd like to get the doc updated in time = for Prague so that we have a clear reference point for discussion there = and then.
 
Unclear why you would post = a change when it was Mike that did this work. Am I missing = something?
 
Mike: would you update the doc with = what you think is rough consensus when you have time so that we can have = a crisp discussion in Prague?
 
 
 
On Wed, Jun 28, 2017 at 5:38 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> = wrote:
I agree on the exp part. 
 
Regarding the second part. = I would like to see more discussion. 
 
For example, in the the = use cases, there may be compatibility issues if different set profiles = cannot be sent over the same stream. 
 
Such profiles should avoid = things like requiring signing and encryption without consideration = regarding how they are transferred.  Also key management might be = better tied up in how the streams are manages because the network = relationship may define the requirements rather than the data. 
 
My initial reaction is, = the profiles should stick to the data and valid interpretation. 

If the group agrees I will merge the exp and = post over the weekend. 
 
I can merge the second = part if there is a strong agreement to do so. 
 
Thanks!

Phil


On = Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you = Mike for working on this. I'm very happy with the change regarding the = "exp" claim, and believe it is the best resolution to the "ID Token" = confusion concern.
 
By making the "exp" claim that is already NOT RECOMMENDED in the = current draft a MUST NOT, we can provide the ID Tokens and SET = uniqueness guarantee that is desired, allowing these two types of JWTs = to be used with a common issuer. This also allows "sub" to be used for = its intended purpose (as defined by RFC7519) without modification, which = other working groups that wish to profile SET have expressed an interest = to do
 
The benefit the community will gain = from the SET standard overall is a standard way to express events that = won't conflict with ID Token (no "iss" partitioning required). With = Mike's changes we achieve that, and in a way that retains the original = simplicity, extensibility and generalizability goals of SET by not = redefining any of JWT's standard claims.
 
 
On Wed, Jun 28, 2017 at 5:08 PM, Mike = Jones <Michael.Jones@microsoft.com> wrote:
Hi folks,
 
I wanted to give you a heads-up about = two SET spec updates in the current editor=E2=80=99s draft before they = are published.
 
The first solves the potential ID Token / SET confusion = problem by requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D= claim when ID Tokens could also be generated by the same issuer.  = Because =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would = therefore be rejected by existing ID Token validation code.  Note = that this solution is already recommended in the specification.  = The editor=E2=80=99s draft update makes this solution mandatory.  = This provides a simple and durable solution to the problem we agreed to = solve at IETF 98 in Chicago and that has been the subject of much = discussion since.
 
The second adds the following new section:
 
Requirements for SET = Profiles
 
Profile Specifications for SETs define the syntax and = semantics of SETs conforming to that SET profile and rules for = validating those SETs. The syntax defined by profiling specifications = includes what claims and event payload values are used by SETs utilizing = the profile.
 
Defining the semantics of the SET contents for SETs utilizing = the profile is equally important. Possibly most important is defining = the procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses = the iss claim value as its = input.
 
Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid.
 
It=E2=80=99s included to inform profile = writers about what they must do to be able to use SETs securely.  = While much of the discussion as of late has been about syntax, semantics = is equally important, and must be considered by profile writers and = deployers.
 
I believe that the new section contains only statements that = are already factually accurate requirements but that were previously = unstated.  The editor=E2=80=99s draft makes these requirements = explicit.  Feedback on how to make these requirements even more = clear, is of course, welcomed.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjU= eXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D
 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
-- 
Nat Sakimura
Chairman of the Board, OpenID Foundation
<= /blockquote>
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
=
= --Apple-Mail=_FB1B9A3F-6768-4723-924C-D498438EC6AC-- From nobody Fri Jun 30 14:16:41 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297D3129AE7 for ; Fri, 30 Jun 2017 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDe541M0LAUw for ; Fri, 30 Jun 2017 14:16:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F38129B55 for ; Fri, 30 Jun 2017 14:16:36 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5ULGWg9013526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 21:16:33 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5ULGV2n002124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Jun 2017 21:16:32 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v5ULGTRv019358; Fri, 30 Jun 2017 21:16:30 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Jun 2017 14:15:37 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_72578930-FC70-4F2D-96F4-670B51CFBBCB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 14:15:27 -0700 In-Reply-To: <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> Cc: Mike Jones , William Denniss , Nat Sakimura , "id-event@ietf.org" , Dick Hardt To: Justin Richer References: <026A9FDB-A994-42BE-A169-2084B51BA50F@oracle.com> <6C875BE5-CAE3-4A72-9129-E5BCA46E71F2@oracle.com> <65B0DCA8-4D26-4CC6-B542-3B8E1643127C@oracle.com> <70D28165-E137-4152-865F-6DEBD02D0EF7@mit.edu> X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 21:16:40 -0000 --Apple-Mail=_72578930-FC70-4F2D-96F4-670B51CFBBCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 AFAIK, sub-profiles of a content format use the + notation as Mike = indicates. application/secevent+jwt makes sense. =20 I am about to publish a delivery draft contribution. I will update it = to use application/secevent+jwt instead of application/jwt. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 30, 2017, at 2:05 PM, Justin Richer wrote: >=20 > Unless there=E2=80=99s an encoding for security events other than JWT, = wouldn=E2=80=99t application/secevent suffice? >=20 > =E2=80=94 Justin >=20 >> On Jun 30, 2017, at 12:56 PM, Mike Jones > wrote: >>=20 >> There had already been discussions, both in Chicago, and in the JWT = BCP context, that if we were going to use a type identifier, we would = use the existing =E2=80=9Ctyp=E2=80=9D header parameter and not create a = new claim. This is a MIME type, with the ability to omit = =E2=80=9Capplication/=E2=80=9D for space reasons, if desired. >> =20 >> Since there appears to be broad interest in having the ability to use = explicit typing of the SET, I will plan to define the = =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the SET draft = before publishing. SETs could then include the = =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2=80=9D header parameter = value to provide explicit typing. Unless I hear objections soon, I will = proceed on this basis. >> =20 >> -- Mike >> =C2=A0 <> >> From: William Denniss [mailto:wdenniss@google.com = ]=20 >> Sent: Friday, June 30, 2017 9:33 AM >> To: Phil Hunt (IDM) > >> Cc: Nat Sakimura >; = Dick Hardt >; Mike = Jones >; id-event@ietf.org = >> Subject: Re: [Id-event] Heads-up about SET spec updates >> =20 >> +1 to typ. >> =20 >> So "typ": "set" or "typ": "event"? >> =20 >> On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) = > wrote: >> +1 to typ claim.=20 >>=20 >> Phil >>=20 >> On Jun 29, 2017, at 5:01 PM, Nat Sakimura > wrote: >>=20 >> Sorry for a tardy reply, but +1 for the both changes. 'exp' claim = requirement is a good practical step with a backward compatibility.=20 >> Having said that, I believe inferring message types from the = existence/absence of a claim is not a good security practice. I would = like to see an explicit typing through "typ" claim added as well.=20 >> =20 >> Nat >> =20 >> On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) > wrote: >> Ok.=20 >> =20 >> I spoke with Mike and he will post his changes to SET in a new = revision over the weekend.=20 >> =20 >> Phil >>=20 >> On Jun 29, 2017, at 1:51 PM, Dick Hardt > wrote: >>=20 >> I understand it is new and that there is contention.=20 >> =20 >> We clearly want consensus for us to be done with the draft. I think = having it in the next draft anchors the discussion so we can discuss and = arrive at consensus or an alternative.=20 >> =20 >> So yes, is like a new draft posted so we can discuss.=20 >> =20 >> On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt > wrote: >> Dick, >> =20 >> The section is a brand new section. It seems to me that has not been = any (or limited) discussion to warrant putting it in the document. It = certainly came to me as a surprise. >> =20 >> I think the issue of trust model needs to be discussed. It may not = belong here at all. >> =20 >> Please advise. Do you want it posted in spite of consensus? >> =20 >> Phil >> =20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com = >> phil.hunt@oracle.com >> =20 >> On Jun 29, 2017, at 12:25 PM, Dick Hardt > wrote: >> =20 >> Hi Phil >> =20 >> wrt asking for more discussion, I appreciate you making the = suggestion on behalf of the chairs. It does seem there is a reasonable = amount of discussion going on now would you not agree? >> =20 >> I'd like to get the doc updated in time for Prague so that we have a = clear reference point for discussion there and then. >> =20 >> Unclear why you would post a change when it was Mike that did this = work. Am I missing something? >> =20 >> Mike: would you update the doc with what you think is rough consensus = when you have time so that we can have a crisp discussion in Prague? >> =20 >> =20 >> =20 >> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) = > wrote: >> I agree on the exp part.=20 >> =20 >> Regarding the second part. I would like to see more discussion.=20 >> =20 >> For example, in the the use cases, there may be compatibility issues = if different set profiles cannot be sent over the same stream.=20 >> =20 >> Such profiles should avoid things like requiring signing and = encryption without consideration regarding how they are transferred. = Also key management might be better tied up in how the streams are = manages because the network relationship may define the requirements = rather than the data.=20 >> =20 >> My initial reaction is, the profiles should stick to the data and = valid interpretation.=20 >>=20 >> If the group agrees I will merge the exp and post over the weekend.=20= >> =20 >> I can merge the second part if there is a strong agreement to do so.=20= >> =20 >> Thanks! >>=20 >> Phil >>=20 >> On Jun 28, 2017, at 5:24 PM, William Denniss > wrote: >>=20 >> Thank you Mike for working on this. I'm very happy with the change = regarding the "exp" claim, and believe it is the best resolution to the = "ID Token" confusion concern. >> =20 >> By making the "exp" claim that is already = NOT RECOMMENDED in the current = draft a MUST NOT, we can provide the ID Tokens and SET uniqueness = guarantee that is desired, allowing these two types of JWTs to be used = with a common issuer. This also allows "sub" to be used for its intended = purpose (as defined by RFC7519) without modification, which other = working groups that wish to profile SET have expressed an interest to do >> =20 >> The benefit the community will gain from the SET standard overall is = a standard way to express events that won't conflict with ID Token (no = "iss" partitioning required). With Mike's changes we achieve that, and = in a way that retains the original simplicity, extensibility and = generalizability goals of SET by not redefining any of JWT's standard = claims. >> =20 >> =20 >> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones = > = wrote: >> Hi folks, >> =20 >> I wanted to give you a heads-up about two SET spec updates in the = current editor=E2=80=99s draft before they are published. >> =20 >> The first solves the potential ID Token / SET confusion problem by = requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim = when ID Tokens could also be generated by the same issuer. Because = =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would therefore = be rejected by existing ID Token validation code. Note that this = solution is already recommended in the specification. The editor=E2=80=99= s draft update makes this solution mandatory. This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since. >> =20 >> The second adds the following new section: >> =20 >> Requirements for SET Profiles >> =20 >> Profile Specifications for SETs define the syntax and semantics of = SETs conforming to that SET profile and rules for validating those SETs. = The syntax defined by profiling specifications includes what claims and = event payload values are used by SETs utilizing the profile. >> =20 >> Defining the semantics of the SET contents for SETs utilizing the = profile is equally important. Possibly most important is defining the = procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses the = iss claim value as its input. >> =20 >> Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid. >> =20 >> It=E2=80=99s included to inform profile writers about what they must = do to be able to use SETs securely. While much of the discussion as of = late has been about syntax, semantics is equally important, and must be = considered by profile writers and deployers. >> =20 >> I believe that the new section contains only statements that are = already factually accurate requirements but that were previously = unstated. The editor=E2=80=99s draft makes these requirements explicit. = Feedback on how to make these requirements even more clear, is of = course, welcomed. >> =20 >> Best = wishes, >> -- = Mike >> =20 >> =20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-= CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUx= KQ&e=3D = >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >>=20 >> =20 >> --=20 >> Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DETbGIxRZLcQfYZt= YUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBN= GE&e=3D = >> =20 >> --=20 >> Subscribe to the HARDTWARE = mail list to = learn about projects I am working on! >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = >> --=20 >> Nat Sakimura >>=20 >> Chairman of the Board, OpenID Foundation >>=20 >> =20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_72578930-FC70-4F2D-96F4-670B51CFBBCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 AFAIK, sub-profiles of a content format use the + notation as = Mike indicates.

application/secevent+jwt makes sense.  

I am about to publish a = delivery draft contribution.  I will update it to use = application/secevent+jwt instead of application/jwt.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 30, 2017, at 2:05 PM, Justin Richer <jricher@mit.edu> = wrote:

Unless there=E2=80=99s = an encoding for security events other than JWT, wouldn=E2=80=99t = application/secevent suffice?

 =E2=80=94 Justin

On Jun = 30, 2017, at 12:56 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

There had = already been discussions, both in Chicago, and in the JWT BCP context, = that if we were going to use a type identifier, we would use the = existing =E2=80=9Ctyp=E2=80=9D header parameter and not create a new = claim.  This is a MIME type, with the ability to omit = =E2=80=9Capplication/=E2=80=9D for space reasons, if desired.
 
Since there = appears to be broad interest in having the ability to use explicit = typing of the SET, I will plan to define the = =E2=80=9Capplication/secevent+jwt=E2=80=9D MIME type in the SET draft = before publishing.  SETs could then include the = =E2=80=9Ctyp=E2=80=9D:=E2=80=9Csecevent+jwt=E2=80=9D header parameter = value to provide explicit typing.  Unless I hear objections soon, I = will proceed on this basis.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: William Denniss [mailto:wdenniss@google.com] 
Sent: Friday, June 30, 2017 9:33 = AM
To: Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: Nat = Sakimura <sakimura@gmail.com>; Dick Hardt <dick.hardt@gmail.com>; Mike Jones <Michael.Jones@microsoft.com>; id-event@ietf.org
Subject: Re: [Id-event] Heads-up = about SET spec updates
 
+1 to typ.
 
So "typ": "set" or "typ": "event"?
 
On Thu, Jun 29, 2017 at 5:17 PM, Phil = Hunt (IDM) <phil.hunt@oracle.com> wrote:
+1 to typ claim. 

Phil


On = Jun 29, 2017, at 5:01 PM, Nat Sakimura <sakimura@gmail.com>= wrote:

Sorry for a tardy reply, but +1 = for the both changes. 'exp' claim requirement is a good practical step = with a backward compatibility. 
Having said that, I = believe inferring message types from the existence/absence of a claim is = not a good security practice. I would like to see an explicit typing = through "typ" claim added as well. 
 
Nat
 
On Fri, Jun 30, 2017 at = 7:04 AM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Ok. 
 
I spoke = with Mike and he will post his changes to SET in a new revision over the = weekend. 
 
Phil


On Jun 29, 2017, at = 1:51 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I understand it is new and = that there is contention. 
 
We clearly want consensus for us to be done with the draft. I = think having it in the next draft anchors the discussion so we can = discuss and arrive at consensus or an alternative. 
 
So yes, is like a new draft posted so = we can discuss. 
 
On Thu, = Jun 29, 2017 at 12:58 PM Phil Hunt <phil.hunt@oracle.com> wrote:
Dick,
 
The section is a brand new section. It seems to me that has = not been any (or limited) discussion to warrant putting it in the = document.  It certainly came to me as a surprise.
 
I think the issue of trust model needs = to be discussed.  It may not belong here at all.
 
Please advise.  Do you want it = posted in spite of consensus?
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect & = Standards
@independentid
www.independentid.com
phil.hunt@oracle.com
 
On Jun 29, 2017, at 12:25 = PM, Dick Hardt <dick.hardt@gmail.com> wrote:
 
Hi = Phil
 
wrt asking for more discussion, I = appreciate you making the suggestion on behalf of the chairs. It does = seem there is a reasonable amount of discussion going on now would you = not agree?
 
I'd like to get the doc updated in time for Prague so that we = have a clear reference point for discussion there and then.
 
Unclear why you would post = a change when it was Mike that did this work. Am I missing = something?
 
Mike: would you update the doc with what you think is rough = consensus when you have time so that we can have a crisp discussion in = Prague?
 
 
 
On Wed, Jun 28, 2017 at = 5:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
I= agree on the exp part. 
 
Regarding the second part. I would like = to see more discussion. 
 
For example, in the the use cases, = there may be compatibility issues if different set profiles cannot be = sent over the same stream. 
 
Such profiles should avoid things like = requiring signing and encryption without consideration regarding how = they are transferred.  Also key management might be better tied up = in how the streams are manages because the network relationship may = define the requirements rather than the data. 
 
My initial reaction is, the profiles = should stick to the data and valid interpretation. 
If the group agrees I will merge the exp and post over the = weekend. 
 
I can merge the second part if there is = a strong agreement to do so. 
 
Thanks!

Phil


On = Jun 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

Thank you Mike for working = on this. I'm very happy with the change regarding the "exp" claim, and = believe it is the best resolution to the "ID Token" confusion = concern.
 
By making the "exp" claim that is already NOT RECOMMENDED in the = current draft a MUST NOT, we can provide the ID Tokens and SET = uniqueness guarantee that is desired, allowing these two types of JWTs = to be used with a common issuer. This also allows "sub" to be used for = its intended purpose (as defined by RFC7519) without modification, which = other working groups that wish to profile SET have expressed an interest = to do
 
The benefit the community will gain from the SET standard = overall is a standard way to express events that won't conflict with ID = Token (no "iss" partitioning required). With Mike's changes we achieve = that, and in a way that retains the original simplicity, extensibility = and generalizability goals of SET by not redefining any of JWT's = standard claims.
 
 
On Wed, Jun 28, 2017 at = 5:08 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Hi folks,
 
I wanted to give you a heads-up about two SET spec updates in = the current editor=E2=80=99s draft before they are published.
 
The first = solves the potential ID Token / SET confusion problem by requiring that = SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim when ID Tokens = could also be generated by the same issuer.  Because =E2=80=9Cexp=E2=80= =9D is a required ID Token claim, SETs would therefore be rejected by = existing ID Token validation code.  Note that this solution is = already recommended in the specification.  The editor=E2=80=99s = draft update makes this solution mandatory.  This provides a simple = and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since.
 
The = second adds the following new section:
 
Requirements for SET = Profiles
 
Profile Specifications for SETs define the syntax and = semantics of SETs conforming to that SET profile and rules for = validating those SETs. The syntax defined by profiling specifications = includes what claims and event payload values are used by SETs utilizing = the profile.
 
Defining the semantics of the SET contents for SETs utilizing = the profile is equally important. Possibly most important is defining = the procedures used to validate the SET issuer and to obtain the keys = controlled by the issuer that were used for cryptographic operations = used in the JWT representing the SET. For instance, some profiles may = define an algorithm for retrieving the SET issuer's keys that uses = the iss claim value as its = input.
 
Profile Specifications MUST clearly specify the steps that a = recipient of a SET utilizing that profile MUST perform to validate that = the SET is both syntactically and semantically valid.
 
It=E2=80=99= s included to inform profile writers about what they must do to be able = to use SETs securely.  While much of the discussion as of late has = been about syntax, semantics is equally important, and must be = considered by profile writers and deployers.
 
I believe = that the new section contains only statements that are already factually = accurate requirements but that were previously unstated.  The = editor=E2=80=99s draft makes these requirements explicit.  Feedback = on how to make these requirements even more clear, is of course, = welcomed.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
 


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3DETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3DlMSowbDnjU= eXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=3D
 
-- 
Subscribe to the HARDTWARE mail list to learn about = projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
-- 

Nat = Sakimura

Chairman of the Board, = OpenID Foundation

 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event=
= --Apple-Mail=_72578930-FC70-4F2D-96F4-670B51CFBBCB-- From nobody Fri Jun 30 15:17:19 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DED127977 for ; Fri, 30 Jun 2017 15:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5QhNiIFf9MS for ; Fri, 30 Jun 2017 15:17:14 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7794126E3A for ; Fri, 30 Jun 2017 15:17:13 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id r30so109718476qtc.0 for ; Fri, 30 Jun 2017 15:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KXaQi/TfzuaqfRmC0/hIN1IdoMXpj4D0ZkQ8j1HeSnM=; b=yvIlQLtBMIiYK8r14DrYhB6CDGwwp8S3RCF67qzK5O04kB3PTVtgvI2/6ExO1a8deL 7Lck6L6iCpEX9/qMrExhTL0CIXnH4xhlfsXRg7rMiNcMwmgIIwIwasJNfn29hTtooJO4 5ahErib6gdSWca50ZmfOfNQh5VIWXThVlojJQzM0F2H8dcCX7Dpajl+hg/KL5/ps4TVB KQnWi0XF7WFy/W1giE1cYq3htydtQDj6G4ZMsCjUB7EhZaJbkNscl0dq3yWpZU5dVjae 9Pi49Ewm6L/V6lbfqpUqp84RPV5Y8otDBmwLYvqbdBntVo8oxJFmA+3F9PneWh/yGM6c 1S0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KXaQi/TfzuaqfRmC0/hIN1IdoMXpj4D0ZkQ8j1HeSnM=; b=Xs5T6b4no0pKyGc9b56h4nUZW/RbiQbaSOQl9RvSFhvR2cUGLgx3oJxwz4P19sHkQ6 b9wCb6jYUsz0wgRwoUuHq5zqkIKHyrUFnRF57uTlCYvjzToZtg+Phimh6hJIqM9VBuDt p9VIZGM4gz6AxL1MH6DbTGCDGrdFM4svHu5xCJBmFTnF27zwKB4o2riLMX1RnUxFi9bT BP+Y3+5YR4OJ4wJZV3+Ua8LboqWdQ/U73meDboKEydjq8gpfMKzMoWjPtRz7BwYwKSGs o+wjeImPzxCD4Ji0/LoE0vG3qX2hVyc0m+puTHucTeOgczNyZTE5avvgdY6FUoYNbOB3 foFQ== X-Gm-Message-State: AKS2vOw4tG93z7q+t5ZutsW1Wdj4SCbfmssaArECtI22fVc505noSHLH 4Ep/VIse4xkKH7bJxKx6HkOWxCoapH/8 X-Received: by 10.237.32.177 with SMTP id 46mr28635130qtb.56.1498861032790; Fri, 30 Jun 2017 15:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.58.225 with HTTP; Fri, 30 Jun 2017 15:17:12 -0700 (PDT) Received: by 10.200.58.225 with HTTP; Fri, 30 Jun 2017 15:17:12 -0700 (PDT) In-Reply-To: References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> From: John Bradley Date: Fri, 30 Jun 2017 18:17:12 -0400 Message-ID: To: Marius Scurtescu Cc: Phil Hunt , William Denniss , "id-event@ietf.org" , Michael Jones Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0ca4ea7244c1055334c72f" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 22:17:17 -0000 --94eb2c0ca4ea7244c1055334c72f Content-Type: multipart/alternative; boundary="94eb2c0ca4ea6d716b055334c7ff" --94eb2c0ca4ea6d716b055334c7ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having the sender publish the key location or key directly in the message has even more trust issues. It is great for attackers if the receiver doesn't verify the key belongs to the claimed issuer. John B. On Jun 29, 2017 2:02 PM, "Marius Scurtescu" wrote: > +1 for exp > > If we allow only one profile per SET then maybe we need a profile URI and > this URI should be present as a top level claim? Or even adding the profi= le > URI to the JWT header? > > Having to fully parse the SET to infer the profile based on event types > only to very the signature does not sound right. Also, mapping from event > type URIs to profiles is not clear. Imagine a receiver that accepts event= s > (it must validate at least syntax and signatures) then further distribute= s > them based on either audience or event type. You don't want to update thi= s > receiver every single time a profile adds a new event type. > > Another potential solution for key location is to have the transmitter > explicitly publish it, as mentioned in another email thread. > > We still have one open issue: SET issuer vs sub context issuer. Asking > profiles to deal with this does not sound safe nor enough to me. > > Marius > > On Thu, Jun 29, 2017 at 10:37 AM, John Bradley wrote: > >> I agree on exp. >> >> I think defining trust relationships should be in the profiles as they >> may be quite different. >> >> That is why mixing events in the same message will be a problem. I >> thought we agreed on that. >> >> Trying to define a fixed trust relationship for the transport is likely >> going to cause people to roll there own. >> >> Even in Connect for specific verticals like finance we see diffrences in >> registration etc to reflect the need to accommodate eIDS and other >> regulations. >> >> One size fits all is great if you are the one size. >> >> I do think we should encourage people to use JWKS URI discovers from >> issuer meta-data based on the issuers well-known as a pattern that has >> proven to be repeatable. >> >> It would be nice if we had those specs done in the IETF:) >> >> John B. >> >> >> On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) >> wrote: >> >> I agree on the exp part. >> >> Regarding the second part. I would like to see more discussion. >> >> For example, in the the use cases, there may be compatibility issues if >> different set profiles cannot be sent over the same stream. >> >> Such profiles should avoid things like requiring signing and encryption >> without consideration regarding how they are transferred. Also key >> management might be better tied up in how the streams are manages becaus= e >> the network relationship may define the requirements rather than the dat= a. >> >> My initial reaction is, the profiles should stick to the data and valid >> interpretation. >> >> If the group agrees I will merge the exp and post over the weekend. >> >> I can merge the second part if there is a strong agreement to do so. >> >> Thanks! >> >> Phil >> >> On Jun 28, 2017, at 5:24 PM, William Denniss wrote= : >> >> Thank you Mike for working on this. I'm very happy with the change >> regarding the "exp" claim, and believe it is the best resolution to the = "ID >> Token" confusion concern. >> >> By making the "exp" claim that is already >> >> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID >> Tokens and SET uniqueness guarantee that is desired, allowing these two >> types of JWTs to be used with a common issuer. This also allows "sub" to= be >> used for its intended purpose (as defined by RFC7519) without modificati= on, >> which other working groups that wish to profile SET have expressed an >> interest to do >> >> The benefit the community will gain from the SET standard overall is a >> standard way to express events that won't conflict with ID Token (no "is= s" >> partitioning required). With Mike's changes we achieve that, and in a wa= y >> that retains the original simplicity, extensibility and generalizability >> goals of SET by not redefining any of JWT's standard claims. >> >> >> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones >> wrote: >> >>> Hi folks, >>> >>> >>> >>> I wanted to give you a heads-up about two SET spec updates in the >>> current editor=E2=80=99s draft before they are published. >>> >>> >>> >>> The first solves the potential ID Token / SET confusion problem by >>> requiring that SETs not include a top-level =E2=80=9Cexp=E2=80=9D claim= when ID Tokens >>> could also be generated by the same issuer. Because =E2=80=9Cexp=E2=80= =9D is a required ID >>> Token claim, SETs would therefore be rejected by existing ID Token >>> validation code. Note that this solution is already recommended in the >>> specification. The editor=E2=80=99s draft update makes this solution m= andatory. >>> This provides a simple and durable solution to the problem we agreed to >>> solve at IETF 98 in Chicago and that has been the subject of much >>> discussion since. >>> >>> >>> >>> The second adds the following new section: >>> >>> >>> >>> Requirements for SET Profiles >>> >>> >>> >>> Profile Specifications for SETs define the syntax and semantics of SETs >>> conforming to that SET profile and rules for validating those SETs. The >>> syntax defined by profiling specifications includes what claims and eve= nt >>> payload values are used by SETs utilizing the profile. >>> >>> >>> >>> Defining the semantics of the SET contents for SETs utilizing the >>> profile is equally important. Possibly most important is defining the >>> procedures used to validate the SET issuer and to obtain the keys >>> controlled by the issuer that were used for cryptographic operations us= ed >>> in the JWT representing the SET. For instance, some profiles may define= an >>> algorithm for retrieving the SET issuer's keys that uses the iss claim >>> value as its input. >>> >>> >>> >>> Profile Specifications MUST clearly specify the steps that a recipient >>> of a SET utilizing that profile MUST perform to validate that the SET i= s >>> both syntactically and semantically valid. >>> >>> >>> >>> It=E2=80=99s included to inform profile writers about what they must do= to be >>> able to use SETs securely. While much of the discussion as of late has >>> been about syntax, semantics is equally important, and must be consider= ed >>> by profile writers and deployers. >>> >>> >>> >>> I believe that the new section contains only statements that are alread= y >>> factually accurate requirements but that were previously unstated. The >>> editor=E2=80=99s draft makes these requirements explicit. Feedback on = how to make >>> these requirements even more clear, is of course, welcomed. >>> >>> >>> >>> Best >>> wishes, >>> >>> -- Mike >>> >>> >>> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz >> jWwlNKe4C_lLIGk&m=3D_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH >> 0&s=3D3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=3D >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> > --94eb2c0ca4ea6d716b055334c7ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having the sender publish the key location or key directl= y in the message has even more trust issues. =C2=A0

It is great for attackers if the receiver doesn't= verify the key belongs to the claimed issuer. =C2=A0

John B. =C2=A0


On J= un 29, 2017 2:02 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote:
+1 for exp

If we allow only one profile per SET then maybe we need a profile = URI and this URI should be present as a top level claim? Or even adding the= profile URI to the JWT header?

Having to fully pa= rse the SET to infer the profile based on event types only to very the sign= ature does not sound right. Also, mapping from event type URIs to profiles = is not clear. Imagine a receiver that accepts events (it must validate at l= east syntax and signatures) then further distributes them based on either a= udience or event type. You don't want to update this receiver every sin= gle time a profile adds a new event type.

Another = potential solution for key location is to have the transmitter explicitly p= ublish it, as mentioned in another email thread.

W= e still have one open issue: SET issuer vs sub context issuer. Asking profi= les to deal with this does not sound safe nor enough to me.

Marius

On Thu, Jun 29, 2017 at 10:37 AM, John Bradl= ey <ve7jtb@ve7jtb.com> wrote:
I agree on exp.

= I think defining trust relationships should be in the profiles as they may = be quite different.

That is why mixing events in t= he same message will be a problem.=C2=A0 I thought we agreed on that.
=

Trying to define a fixed trust relationship for the tra= nsport is likely going to cause people to roll there own.

Even in Connect for specific verticals like finance we see diffrenc= es in registration etc to reflect the need to accommodate eIDS and other re= gulations.

One size fits all is great if you are t= he one size. =C2=A0

I do think we should encourage= people to use JWKS URI discovers from issuer meta-data based on the issuer= s well-known as a pattern that has proven to be repeatable.=C2=A0

It would be nice if we had those specs done in the IETF:)

John B.


On Jun 2= 8, 2017, at 8:38 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

<= /div>
I agree on the= exp part.=C2=A0

Regarding the second part. I would like to = see more discussion.=C2=A0

For example, in the the use cases= , there may be compatibility issues if different set profiles cannot be sen= t over the same stream.=C2=A0

Such profiles should avoid thi= ngs like requiring signing and encryption without consideration regarding h= ow they are transferred.=C2=A0 Also key management might be better tied up = in how the streams are manages because the network relationship may define = the requirements rather than the data.=C2=A0

My initial reac= tion is, the profiles should stick to the data and valid interpretation.=C2= =A0

If the group agrees I will merge the exp and post over the weeke= nd.=C2=A0

I can merge the second part if there is a strong a= greement to do so.=C2=A0

Thanks!

Phil

On J= un 28, 2017, at 5:24 PM, William Denniss <wdenniss@google.com> wrote:

=
Thank you Mike for working = on this. I'm very happy with the change regarding the "exp" c= laim, and believe it is the best resolution to the "ID Token" con= fusion concern.

By making the "exp" clai= m that is=C2=A0already=C2=A0NO= T RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens= and SET uniqueness guarantee that is desired, allowing these two types of = JWTs to be used with a common issuer. This also allows "sub" to b= e used for its intended purpose (as defined by RFC7519) without modificatio= n, which other working groups that wish to profile SET have expressed an in= terest to do

The benefit the community will gain f= rom the SET standard overall is a standard way to express events that won&#= 39;t conflict with ID Token (no "iss" partitioning required). Wit= h Mike's changes we achieve that, and in a way that retains the origina= l simplicity, extensibility and generalizability goals of SET by not redefi= ning any of JWT's standard claims.


On Wed, Jun 28, 2017 at 5:0= 8 PM, Mike Jones=C2=A0<Michael.Jones@microsoft= .com>=C2=A0wrote:

Hi folks,

=C2=A0=

I wanted to give you a heads-up about two= SET spec updates in the current editor=E2=80=99s draft before they are pub= lished.

=C2=A0

The first solves the potential ID Token / SET confusion= problem by requiring that SETs not include a top-level =E2=80=9Cexp=E2=80= =9D claim when ID Tokens could also be generated by the same issuer.=C2=A0 = Because =E2=80=9Cexp=E2=80=9D is a required ID Token claim, SETs would ther= efore be rejected by existing ID Token validation code.=C2=A0 Note that thi= s solution is already recommended in the specification.=C2=A0 The editor=E2= =80=99s draft update makes this solution mandatory.=C2=A0 This provides a s= imple and durable solution to the problem we agreed to solve at IETF 98 in = Chicago and that has been the subject of much discussion since.

=C2=A0

The second adds the following new section:

=C2=A0

Requirements for SET Profiles<= /p>

=C2=A0

Profile Spe= cifications for SETs define the syntax and semantics of SETs conforming to = that SET profile and rules for validating those SETs. The syntax defined by= profiling specifications includes what claims and event payload values are= used by SETs utilizing the profile.

=C2=A0

Defining the semantics of th= e SET contents for SETs utilizing the profile is equally important. Possibl= y most important is defining the procedures used to validate the SET issuer= and to obtain the keys controlled by the issuer that were used for cryptog= raphic operations used in the JWT representing the SET. For instance, some = profiles may define an algorithm for retrieving the SET issuer's keys t= hat uses the=C2=A0iss=C2=A0claim= value as its input.

=C2= =A0

Profile Specifications MUST clearly spe= cify the steps that a recipient of a SET utilizing that profile MUST perfor= m to validate that the SET is both syntactically and semantically valid.=C2=A0

=C2= =A0

It=E2=80=99s included to inform profil= e writers about what they must do to be able to use SETs securely.=C2=A0 Wh= ile much of the discussion as of late has been about syntax, semantics is e= qually important, and must be considered by profile writers and deployers.<= u>

=C2=A0

I believe that the new section contains only statements that ar= e already factually accurate requirements but that were previously unstated= .=C2=A0 The editor=E2=80=99s draft makes these requirements explicit.=C2=A0= Feedback on how to make these requirements even more clear, is of course, = welcomed.

=C2=A0

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

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

=C2=A0


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https:= //www.ietf.org/mailman/listinfo/id-event
<= br>

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--94eb2c0ca4ea6d716b055334c7ff-- --94eb2c0ca4ea7244c1055334c72f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIC5jFiktriOiuSpsLW+dLI6bAsGu QPC5QFtFw9UPE7vEMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDYzMDIyMTcxM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAsAE7JZSmPmY5iDXSJjxiDyTCcteSZASEd/4DW6D/lYfDk Nl2JAsJL7fFI2h7Wil4habH69L+PzLnHfQuMF76Jyqa4tdpN8ttq9AuwO8mDgPHosc+juatX5Yop 4DiOCWOfvQc16AKm+KIuzJyXrjytNiIjneZyCrKHi1gxNWfTn0drsaaV6tMvt5Q3GvsMUwHwjvPI giSekNghcXlL4aeV9P6mZdt815lL84eP6AhPAVs14Nhbtd4Ug7MkAACQSsOnejhg3mQ/pEztFHfP iptfEL0kOzQZIwUa/9o3nnIpzjcDpPI71doYIzhU8CYN9Z+35cWjhUPD+mA2a718Keao --94eb2c0ca4ea7244c1055334c72f-- From nobody Fri Jun 30 15:31:48 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1DE127977 for ; Fri, 30 Jun 2017 15:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L-Dh_RPZT5l for ; Fri, 30 Jun 2017 15:31:45 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F848129B95 for ; Fri, 30 Jun 2017 15:31:43 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id l13so77512050lfl.1 for ; Fri, 30 Jun 2017 15:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jLKNocIZE1aBaZFVhtb7lQojpuE9OLaLSTezHALvRm0=; b=eN6oYISbvsHCU8NEpLoCklnimBBc1eb60qllJopqvgwlwhoT0mh4l4pGWSHZbxmdiG KZKt7gxAoUmjLmT0gojbJgOUBc6iwYaHrcsv/F1RirZf81E0C4qsB8J6Lo5RteVGJNCH ALNwiU4Eq+6Gt35qWIum2aAIqwLoimZwgi/cpIh9iZxlAboJKYg+Q/sdJ2a1CaQWBvR8 eBrBmneVW5GTww1CZjpC3fN3Tl1O/sn3PV/UpM+RxKTEe/vfZo5gS62r+ffuCDnTb+yO AiD3EjHEIOCrXJ9pbVxWPtUi61IVmhVTUmBqtIbrEvrnGLNAZOpPrQmkS/xUDobIhcyO 0NRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jLKNocIZE1aBaZFVhtb7lQojpuE9OLaLSTezHALvRm0=; b=afF7a1QeM4RwcK1efr1XE4+vPLQeFEzLRp03v5H9PEw6pzj76qBEHUYiTSwIfYFrL/ qacnMZAJsxnD5nM77EBqsevRZBAAqBqTHYsERXbXz5f1+tE/ex0T5dGa9vjLkPw/EHKQ /g5W4JTjUf6YOLDmup0eXnKnypi3VGlOfx43Trk+5PAAsbYNGlSDaac9P6jpItyhW8h8 Ynep9hZYva1AlKnxndilgN+yjTK8vFFN90fH/5m0TePxesD/dv7/YfllrY9ES4jCOS8h bmfHATFXreAMFZmDvQNUwoqj2tbc5Ac3ndo4Z98b5Jq/owu3lzIcYQJlTfPIR8wm+uaP CB0Q== X-Gm-Message-State: AKS2vOwSSLL6WuZL1RsjP1whNrP16OhtJSKwa7J67zV/nGAuE+r+uO+H 0TtWGHAi5r4b54dlcDYamA== X-Received: by 10.46.5.87 with SMTP id 84mr7443867ljf.95.1498861901826; Fri, 30 Jun 2017 15:31:41 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id a6sm1870063ljb.44.2017.06.30.15.31.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 15:31:41 -0700 (PDT) To: id-event@ietf.org References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> From: Leif Johansson Message-ID: <032642f1-355c-2602-bd64-c05353190759@sunet.se> Date: Sat, 1 Jul 2017 00:31:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 22:31:47 -0000 On 2017-07-01 00:17, John Bradley wrote: > Having the sender publish the key location or key directly in the > message has even more trust issues. > > It is great for attackers if the receiver doesn't verify the key belongs > to the claimed issuer. key location essentially ties you to the webpki for trust... we've been here before From nobody Fri Jun 30 16:24:27 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12BE128BC8 for ; Fri, 30 Jun 2017 16:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=openconsentgroup.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4As5YJPbykBU for ; Fri, 30 Jun 2017 16:24:24 -0700 (PDT) Received: from n1nlsmtp02.shr.prod.ams1.secureserver.net (n1nlsmtp02.prod.ams1.secureserver.net [188.121.43.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5501200E5 for ; Fri, 30 Jun 2017 16:24:23 -0700 (PDT) Received: from n1plcpnl0072.prod.ams1.secureserver.net ([188.121.57.6]) by : HOSTING RELAY : with SMTP id R5FxdoPbnWm3ZR5FxdxizJ; Fri, 30 Jun 2017 16:23:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openconsentgroup.com; s=default; h=References:To:Cc:In-Reply-To:Date: Subject:Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ptY4WWn5PnRZiUC0U+NtdJui1RFyMA576YloO5j+BUg=; b=CYcDIHVjc3JFOUGFYwyZuQs05 jmlxwSHVn6huSGDjLRc9UUMWD0TuR3Ke41KOYWXtOz/1Jv/mqa3nRtW+GJ8IeHChoeb4bs21DVAg+ b1lqAtdC9VjSxje2nSqsrA1t9ZXC4Zt8W7oWMUOnnyk7jw22r3LZjwOFfrcctkf/gbuyDBcTBLjZe V1FMudz79JXEjVPWveL2bsDD6ZCMXnERNCOI/3lDh5S+eK6bWn4xNqN1abuTptFBjAJNR/5SiXI9r uZjQyfu3WGtBRoiUItO42obvpya+uC9xJJTfZCzreR+vUYxRPblQnCVJzdqW1VNSgQqTf8cFiRfFr NxhKlz/Pg==; Received: from host-92-28-221-155.as13285.net ([92.28.221.155]:50457 helo=[192.168.1.10]) by n1plcpnl0072.prod.ams1.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1dR5Fv-004DFu-6n; Fri, 30 Jun 2017 16:23:21 -0700 From: "M.Lizar@OCG" Message-Id: <69588DE4-CAEB-4598-A54D-CFB23B285179@openconsentgroup.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DA86D768-D67A-48AF-9123-F72887EFCB36" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 1 Jul 2017 00:23:11 +0100 In-Reply-To: Cc: Mike Jones , "id-event@ietf.org" To: William Denniss References: X-Mailer: Apple Mail (2.3273) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n1plcpnl0072.prod.ams1.secureserver.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openconsentgroup.com X-Get-Message-Sender-Via: n1plcpnl0072.prod.ams1.secureserver.net: authenticated_id: m.lizar@openconsentgroup.com X-Authenticated-Sender: n1plcpnl0072.prod.ams1.secureserver.net: m.lizar@openconsentgroup.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfOxQNgu1sYUEZlseVdphEcfKKTNy0pwEWTeu37lmXvte7Rdc3upje2n1zU7Z5VPksIDcayIy7qmG9qgsPF/5gvCHAnV3A5PxzONxFtIhKyvfGIHvFeRq 1OfIOBXzjgWW580QSR5eC/l3ou+A+WAKFYaZIdDBBdQ7JP5yv20YX23IuNJ3Gn4trNJ0odySSBmJBKPOm49ryZH/mL7C40NYNtI= Archived-At: Subject: Re: [Id-event] Security Event Token (SET) specification preventing token confusion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 23:24:27 -0000 --Apple-Mail=_DA86D768-D67A-48AF-9123-F72887EFCB36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1=20 Appears useful and stable enough now to initiate the WGLC. - Mark > On 30 Jun 2017, at 21:48, William Denniss wrote: >=20 > Thank you Mike. It's good to see the SET - ID Token issue resolved, = and the other positive changes. >=20 > It would be good to publish SET soon, so the working groups that will = be profiling it can get going. With that in mind, should we initiate the = WGLC? >=20 > On Fri, Jun 30, 2017 at 1:40 PM, Mike Jones = > = wrote: > A new version of the Security Event Token (SET) specification has been = published containing measures that prevent any possibility of confusion = between ID Tokens and SETs. Preventing confusion between SETs, access = tokens, and other kinds of JWTs is also covered. Changes were: >=20 > Added the Requirements for SET Profiles section. > Expanded the Security Considerations section to describe how to = prevent confusion of SETs with ID Tokens, access tokens, and other kinds = of JWTs. > Registered the application/secevent+jwt media type and defined how to = use it for explicit typing of SETs. > Clarified the misleading statement that used to say that a SET conveys = a single security event. > Added a note explicitly acknowledging that some SET profiles may = choose to convey event subject information in the event payload. > Corrected an encoded claims set example. > Applied grammar corrections. > =20 >=20 > This draft is intended to provide solutions to the issues that had = been discussed in IETF 98 in Chicago and subsequently on the working = group mailing list. Thanks for all the great discussions that informed = this draft! >=20 > =20 >=20 > The specification is available at: >=20 > https://tools.ietf.org/html/draft-ietf-secevent-token-02 = > =20 >=20 > An HTML-formatted version is also available at: >=20 > http://self-issued.info/docs/draft-ietf-secevent-token-02.html = > =20 >=20 > -- = Mike >=20 > =20 >=20 > P.S. This announcement was also posted at = http://self-issued.info/?p=3D1709 = and as @selfissued . >=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_DA86D768-D67A-48AF-9123-F72887EFCB36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
+1 

Appears useful and stable enough now to initiate = the WGLC.

- = Mark

On 30 Jun 2017, at 21:48, William Denniss <wdenniss@google.com>= wrote:

Thank you Mike. It's good to see the SET - ID = Token issue resolved, and the other positive changes.

It would be good to publish SET soon, = so the working groups that will be profiling it can get going. With that = in mind, should we initiate the WGLC?

On Fri, = Jun 30, 2017 at 1:40 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

A= new version of the Security Event Token (SET) specification has been = published containing measures that prevent any possibility of confusion = between ID Tokens and SETs.  Preventing confusion between SETs, = access tokens, and other kinds of JWTs is also covered.  Changes were:

  • Added the Requirements for SET Profiles = section.
  • Expanded the Security Considerations section = to describe how to prevent confusion of SETs with ID Tokens, access = tokens, and other kinds of JWTs.
  • Registered the application/secevent+jwt media type and defined how to = use it for explicit typing of SETs.
  • Clarified the misleading statement that used = to say that a SET conveys a single security event.
  • Added a note explicitly acknowledging that = some SET profiles may choose to convey event subject information in the = event payload.
  • Corrected an encoded claims set example.
  • Applied grammar corrections.

 

This = draft is intended to provide solutions to the issues that had been = discussed in IETF 98 in Chicago and subsequently on the working group = mailing list.  Thanks for all the great discussions that informed = this draft!

 

The specification is available at:

 

An HTML-formatted version is = also available at:

 

         =             &n= bsp;                  &nb= sp;            = ;           -- Mike

 

P.S.  This announcement = was also posted at http://self-issued.info/?p=3D1709 and as @selfissued.


_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_DA86D768-D67A-48AF-9123-F72887EFCB36-- From nobody Fri Jun 30 16:26:04 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D61B126C7A for ; Fri, 30 Jun 2017 16:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I467bry7KJsU for ; Fri, 30 Jun 2017 16:26:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983FF1200E5 for ; Fri, 30 Jun 2017 16:26:01 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5UNPxbB018547 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 23:26:00 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v5UNPxd2026808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Jun 2017 23:25:59 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v5UNPwhm017250; Fri, 30 Jun 2017 23:25:59 GMT Received: from [10.0.1.7] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Jun 2017 16:25:58 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_52000C75-547F-4A26-A621-345B6D9C6E52" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 30 Jun 2017 16:25:57 -0700 In-Reply-To: <032642f1-355c-2602-bd64-c05353190759@sunet.se> Cc: id-event@ietf.org To: Leif Johansson References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> <032642f1-355c-2602-bd64-c05353190759@sunet.se> X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 23:26:03 -0000 --Apple-Mail=_52000C75-547F-4A26-A621-345B6D9C6E52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not sure where this fork in the thread came from. So, I=E2=80= =99m not exactly sure I=E2=80=99m responding to the right thing. If this is related to my comment, I was concerned that trust bindings = should not be part of SET profiles as this might create major = incompatibilities for cases with SETs from multiple Event Families need = to be distributed as part of a common stream.=20 My thinking is that the Trust relationship is part of the Stream more = than it is a particular type or set of SETS. It=E2=80=99s not that somebody can=E2=80=99t do something highly = specific. I just don=E2=80=99t think they should unless their intention = really is to limit usability. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jun 30, 2017, at 3:31 PM, Leif Johansson wrote: >=20 > On 2017-07-01 00:17, John Bradley wrote: >> Having the sender publish the key location or key directly in the >> message has even more trust issues. =20 >>=20 >> It is great for attackers if the receiver doesn't verify the key = belongs >> to the claimed issuer. =20 >=20 > key location essentially ties you to the webpki for trust... we've = been > here before >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY05= 7SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D0ja-9Vit7qiR1EG= hfDAo_YSSBjUcytWPGD_x7n0VYrE&s=3DB2wBw7YMv11xdZeH4rZPTR0ZBhPia27R_gUgszBul= mc&e=3D=20 --Apple-Mail=_52000C75-547F-4A26-A621-345B6D9C6E52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m not sure where this fork in the thread came from. =  So, I=E2=80=99m not exactly sure I=E2=80=99m responding to the = right thing.

If this = is related to my comment, I was concerned that trust bindings should not = be part of SET profiles as this might create major incompatibilities for = cases with SETs from multiple Event Families need to be distributed as = part of a common stream. 

My thinking is that the Trust = relationship is part of the Stream more than it is a particular type or = set of SETS.

It=E2=80=99s not that somebody can=E2=80=99t do something = highly specific. I just don=E2=80=99t think they should unless their = intention really is to limit usability.

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jun 30, 2017, at 3:31 PM, Leif Johansson <leifj@sunet.se> = wrote:

On 2017-07-01 00:17, John Bradley wrote:
Having the sender = publish the key location or key directly in the
message = has even more trust issues.  

It is = great for attackers if the receiver doesn't verify the key belongs
to the claimed issuer.  

key location essentially ties you to the webpki for trust... = we've been
here before

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lL= IGk&m=3D0ja-9Vit7qiR1EGhfDAo_YSSBjUcytWPGD_x7n0VYrE&s=3DB2wBw7YMv1= 1xdZeH4rZPTR0ZBhPia27R_gUgszBulmc&e=3D

= --Apple-Mail=_52000C75-547F-4A26-A621-345B6D9C6E52-- From nobody Fri Jun 30 19:35:38 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E1F1200C5 for ; Fri, 30 Jun 2017 19:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9p8hLRcKMyv for ; Fri, 30 Jun 2017 19:35:35 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76F312708C for ; Fri, 30 Jun 2017 19:35:34 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id v143so29964208qkb.0 for ; Fri, 30 Jun 2017 19:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bg7TUiOsKxePK2ddWz98bkLPQPXqnuDZfQ+sPWH4LfA=; b=fwyBgf2BLwn4j4TKqmjjmuaBrDryRyZXzCCXOrjBEkxYVs4HkUnRfvFFWDdRiy/eSi 8ah4VJ+OhKSWoMeyFL3gGceI7AkpKcgCCV3fgdC1M4TXyzjwob5s3GbefPQdlZ/vyIz2 lILVhtgbzfmbSPwHqCL8c98+YondpH0Sq/FxiexDksoNf5IDXFOx4TQkgu0EfxtAQ0r4 GHQaY0DVQSL2zQlce2mu6mpKuOmha0iRYLKNdPwpMMXhogQbpMkIRHNMFm66mBxjVU34 rij59dAQ+Vik5l4izHhuanPb2zkPFNwUXC3ZhHz2Yo1TmYhcrYjuPsOdu19peIRsj1IE JIYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bg7TUiOsKxePK2ddWz98bkLPQPXqnuDZfQ+sPWH4LfA=; b=S8lO8bA9rAQtQYMmcIHwDykI5RTUoWXKbbW7efL/lWFtDb9d5bxauHHpKIZq/4OM+7 WNSG2mhPqItNw+7g/PHCJzQbQEOdOz1b26feoePm2D83Z7gm1u1iQtFB7z3GGDB86d9Z 0sWm12Sp7xYAjqJWZ87wRO5aARSLj6eZvqCD/78WrcGFKZn/lhWi/VMk1IQuX4gO/WeM 5WiIiv6itMOk6ODZT1wi3u9ikxUBHyIY0d+g1kfGuiXCs6ax1SjFrvmb/ok0yQubCIL0 jkqdXli1ZhvDbO3tsG9+//rjcrV/4ys1Glko2MY7E9GYYBouMRrbRQoW14ifkQmnALoQ XM1g== X-Gm-Message-State: AIVw110EIdumhS8TTdR5PKQtVJk+aKx7cUkBsWWiOYKh+ayE+bdUwYTP yzMF3ZOER7kMVkzCCp2Z0mvTt3Jln4kR X-Received: by 10.55.143.65 with SMTP id r62mr5824469qkd.69.1498876533541; Fri, 30 Jun 2017 19:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.58.225 with HTTP; Fri, 30 Jun 2017 19:35:32 -0700 (PDT) Received: by 10.200.58.225 with HTTP; Fri, 30 Jun 2017 19:35:32 -0700 (PDT) In-Reply-To: References: <0E61744F-EBAC-4EFC-A48B-3800E044189B@ve7jtb.com> <032642f1-355c-2602-bd64-c05353190759@sunet.se> From: John Bradley Date: Fri, 30 Jun 2017 22:35:32 -0400 Message-ID: To: Phil Hunt Cc: ID Events Mailing List , Leif Johansson Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c083da05ce0860553386389" Archived-At: Subject: Re: [Id-event] Heads-up about SET spec updates X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 02:35:37 -0000 --94eb2c083da05ce0860553386389 Content-Type: multipart/alternative; boundary="94eb2c083da05825700553386362" --94eb2c083da05825700553386362 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We were replying to the post by Marius in the thred. Look at my reply. Leif over snipped. John B. On Jun 30, 2017 7:26 PM, "Phil Hunt" wrote: I=E2=80=99m not sure where this fork in the thread came from. So, I=E2=80= =99m not exactly sure I=E2=80=99m responding to the right thing. If this is related to my comment, I was concerned that trust bindings should not be part of SET profiles as this might create major incompatibilities for cases with SETs from multiple Event Families need to be distributed as part of a common stream. My thinking is that the Trust relationship is part of the Stream more than it is a particular type or set of SETS. It=E2=80=99s not that somebody can=E2=80=99t do something highly specific. = I just don=E2=80=99t think they should unless their intention really is to limit usability. Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com phil.hunt@oracle.com On Jun 30, 2017, at 3:31 PM, Leif Johansson wrote: On 2017-07-01 00:17, John Bradley wrote: Having the sender publish the key location or key directly in the message has even more trust issues. It is great for attackers if the receiver doesn't verify the key belongs to the claimed issuer. key location essentially ties you to the webpki for trust... we've been here before _______________________________________________ Id-event mailing list Id-event@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv= zjW wlNKe4C_lLIGk&m=3D0ja-9Vit7qiR1EGhfDAo_YSSBjUcytWPGD_x7n0VYrE&s=3D B2wBw7YMv11xdZeH4rZPTR0ZBhPia27R_gUgszBulmc&e=3D _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --94eb2c083da05825700553386362 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We were replying to the post by Marius in the thred.= =C2=A0 Look at my reply.=C2=A0 Leif over snipped.
John B.=C2=A0

On Jun 30, 201= 7 7:26 PM, "Phil Hunt" <phil.hunt@oracle.com> wrote:
I=E2=80=99m not sure where = this fork in the thread came from.=C2=A0 So, I=E2=80=99m not exactly sure I= =E2=80=99m responding to the right thing.

If this is rel= ated to my comment, I was concerned that trust bindings should not be part = of SET profiles as this might create major incompatibilities for cases with= SETs from multiple Event Families need to be distributed as part of a comm= on stream.=C2=A0

My thinking is that the Trust rel= ationship is part of the Stream more than it is a particular type or set of= SETS.

It=E2=80=99s not that somebody can=E2=80=99= t do something highly specific. I just don=E2=80=99t think they should unle= ss their intention really is to limit usability.

Phil

Oracle = Corporation, Identity Cloud Services Architect & Standards
@i= ndependentid
phil.hunt@oracle.com

On= Jun 30, 2017, at 3:31 PM, Leif Johansson <leifj@sunet.se> wrote:

On 2017-07-01 00:17, John Bradley wrote:
Having the sender publish the key location or key directly in the=
message has even more trust issues. =C2=A0

It is great for attac= kers if the receiver doesn't verify the key belongs
to the claimed i= ssuer. =C2=A0

key location essentially ties you to the = webpki for trust... we've been
here before

__________________= _____________________________
Id-event mailing list
Id-event@ietf.org
<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8P= QcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&= amp;m=3D0ja-9Vit7qiR1EGhfDAo_YSSBjUcytWPGD_x7n0VYrE&s=3DB2wBw7YMv11xdZe= H4rZPTR0ZBhPia27R_gUgszBulmc&e=3D" target=3D"_blank">https://urldefense= .proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinf= o_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5= YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C= _lLIGk&m=3D0ja-9Vit7qiR1EGhfDAo_YSSBjUcytWPGD_x7n0VYrE&s= =3DB2wBw7YMv11xdZeH4rZPTR0ZBhPia27R_gUgszBulmc&e=3D
<= /div>


_________________________= ______________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


--94eb2c083da05825700553386362-- --94eb2c083da05ce0860553386389 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIIAfrkczQjPInkdahf0gp5cPomGX o3kETYYCu2Hn0zvLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDcwMTAyMzUzM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQDIgeD9Tq3Tp9ZB0M2ZJp7whEwrmCqseiM4vdgUH9+4ClY1 OPqn6tWr5f8v4MPuAJ4BErV322SXtHH6fvMBzohYjLMF6NVkmxx/4x/9mlXp+X9+U8lbHUEWwGsj B/39E7WBIy4jnlR85Ll4TjqjrvS3sav7ZE4BVJ2vtEl7eMjh5mxFEn1rbbC2LIDtggrCxBQhl6oB MpWtusW2wTBGXk6iZDtNrWCTTEBZHP0CKS6ZpDJoCJmbw2M+p5i/kJCl9c89mM97/a+BGf/8W+/P NyuIgFOcxiIy+/NurdSHNMMvx84GV81IV9SuPZEA640Yjrobj1uYEX9ZbqgE14tF+pFo --94eb2c083da05ce0860553386389-- From nobody Fri Jun 30 21:00:11 2017 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC70126C2F for ; Fri, 30 Jun 2017 21:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwgOKrg3I3o3 for ; Fri, 30 Jun 2017 21:00:03 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B30E129B05 for ; Fri, 30 Jun 2017 21:00:03 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id q86so75629113pfl.3 for ; Fri, 30 Jun 2017 21:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=XVLrDcovyoyR/RmI2JoErrK5/QaF/Ek9KhMWjzUY6fk=; b=Og0QIuKx0uRxaG/CO6YhsvdG3askRPXuIB2TsiD3WqdWrG9GVGONU2Lg9T1h//gGkL LDeq/+AXCVTMcLdX7bKEBDusNvZDKl8tqFH3W0Vj6BRKeJeJqkQHyh8R50c40q4mp5tz JVVgG5gT9mDLBb+iIVQsXLgEoIGPzpr6xIkGi4UqLjPxw8IpgOooI1RChzljE3TLPhK9 NnCKr9UvyzmDHUXa86zQPkVYjwJlvys07UJhjuLUeC/OZ4DgQ3GhjzK5BbCHtIZFAAh8 e1FCWMH8w9/feFd47Dc1I/bfs+TiiIrGFnv/272wcsmmHTV7asejQJntQPfOpUyzyhJE SILA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=XVLrDcovyoyR/RmI2JoErrK5/QaF/Ek9KhMWjzUY6fk=; b=fEcSnq/t1XADwVawiDjlXMjm7w2COaTkB6jFOwH+lfea9xIHtSOwv3LWvqFTU5XCdS vq0M8XErLdTxuonru0v7gxJRGNORLUDHtAcPzVdM3gYQYQkgJpVxmMz8orN/oQEQ3/t3 x6HOcZqza7hqGc5aA7sXLwdMjjHdy9zm4IiKUdgcWZXyB8mGsTcewigQGwirUKNzow67 0uNzyOEkVBShsLpJWN3zuicqJ1sziomWVQxxLynzlWNYYbDevoXV3CZgrr7RjmXtWs7E kqawQ95Og99l0OqfNtGXR5DDGNi0vXDKqLhelLlzmsuZ7FcCz74zzJYH9vl34xQaZj7f PU0g== X-Gm-Message-State: AKS2vOyxVBsJD2x93J3pAeRCz7LnDQJqSXH+uBfjVu5PVai2AxhV9wmT WSQh+Xwx0sCZ1Q== X-Received: by 10.101.76.3 with SMTP id u3mr24053827pgq.119.1498881602722; Fri, 30 Jun 2017 21:00:02 -0700 (PDT) Received: from [10.255.171.239] (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id l3sm19921710pfk.34.2017.06.30.21.00.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 21:00:00 -0700 (PDT) To: Mike Jones , Marius Scurtescu , Dick Hardt Cc: SecEvent , Justin Richer , "Phil Hunt (IDM)" References: <2104A459-8402-4498-9F7F-3EED264DB4E8@oracle.com> <2F79A80F-AE98-4372-B096-C26ED77F4C3B@mit.edu> <10de4c6f-c0a7-9d9f-c524-fa87048dd580@gmail.com> From: Yaron Sheffer Message-ID: <340e0d5f-03c5-efbd-f2ba-2725530da424@gmail.com> Date: Fri, 30 Jun 2017 20:59:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Id-event] Use case document X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 04:00:10 -0000 Hi Mike, I think the abstract explains it very clearly: "This document describes the RISC use cases for security events and helps with defining the requirements for token format and event distribution." This is a useful document in the secevent context (though not a working group document). In addition, Marius is free of course to republish his document in RISC or elsewhere. Thanks, Yaron On 29/06/17 17:17, Mike Jones wrote: > > Wearing my OpenID member hat – why isn’t this a RISC working group > document, rather than an SECEVENT working group document? > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of > *Marius Scurtescu > *Sent:* Thursday, June 29, 2017 4:42 PM > *To:* Dick Hardt > *Cc:* Yaron Sheffer ; SecEvent > ; Justin Richer ; Phil Hunt (IDM) > > *Subject:* Re: [Id-event] Use case document > > I just submitted the RISC use cases at: > > https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases-00 > > It is very basic right now, I just wanted to make sure that there is > at least a basic version submitted before the deadline. > > I will expand the descriptions and add diagrams. > > Let me know if anyone else would like to be an author. > > Marius > > > Marius > > On Wed, May 31, 2017 at 6:24 PM, Dick Hardt > wrote: > > Agreed. There is no requirement for these to be in the same document. > > On Wed, May 31, 2017 at 5:33 PM, Phil Hunt (IDM) > > wrote: > > Marius, > > Go ahead an submit as an individual draft. I will submit scim > cases in a separate draft. > > Afaik there is no plan to have this he a single wg document. > > Phil > > > On May 31, 2017, at 9:22 PM, Marius Scurtescu > > wrote: > > Here is an initial use case document, for now it has only > the RISC use cases we discussed so far. When Phil gets > back I will coordinate with him to add SCIM use cases to > this same I-D. I will get this into a decent shape for the > IETF meeting. > > > Marius > > On Thu, May 4, 2017 at 11:28 AM, Yaron Sheffer > > wrote: > > Whatever works for you - and that's the whole point of > *individual* I-Ds. > > Thanks, > > Yaron > > On 04/05/17 18:25, Marius Scurtescu wrote: > > Do we need one document for all use cases (all > profiles) or one for each profiles? > > I am happy to create the one document or the one > for RISC (if one per profile). > > > Marius > > On Thu, May 4, 2017 at 3:36 AM, Yaron Sheffer > > wrote: > > My strong preference would be an individual > I-D that (as Justin says) will NOT be pushed > to RFC. Why an I-D at all? Because this is > what IETF folks are used to, and it is > referenced from the WG agenda and minutes. > > Thanks, > > Yaron > > On 04/05/17 07:57, Justin Richer wrote: > > In fact, I’m going to ask that we *not* > push a use cases document toward RFC. Use > case documents are wonderful tools for > guiding development, but should be > discarded as artifacts of that process > once said process is completed (or even > well on its way). > > As such, RFC, wiki, blog post, or anything > referenced from the list and easily > findable works. > > — Justin > > On May 3, 2017, at 4:45 PM, Dick Hardt > > wrote: > > As the more experienced chair, I will > defer to Yaron for guidance. > > So far no one has expected it to be > adopted as an RFC > > On Wed, May 3, 2017 at 4:39 PM, Phil > Hunt >wrote: > > Depends on what the WG wants. > > Email cases, > > Github posted document, > > Individual IDs posted to the > working group, or > > an ID that gets adopted as a WG > draft to end up as RFC (e.g. JOSE > has RFC7165, and SCIM itself had > RFC7642, Oauth had a WG > drafthttps://tools.ietf.org/html/draft-ietf-oauth-use-cases-03 > ). > > Let us know what form and what format. > > We can also use one for OpenID > Backchannel Logout. This is > particularly important because it > will be triggered by (or is > related to) SCIM and by RISC > events such as account resets, > authentication factor changes etc. > > Phil > > Oracle Corporation, Identity Cloud > Services Architect & Standards > > @independentid > > www.independentid.com > > > phil.hunt@oracle.com > > > On May 3, 2017, at 4:31 PM, > Dick Hardt > > > wrote: > > Hi Phil > > per > > https://mailarchive.ietf.org/arch/msg/id-event/FGuz9IsUMKqKeq2OjEBjCZ9cBcI > > > you offered to put them in a > WG doc (see quate below). > Would that not be an ID. Also, > as I read over the document, > it is hard to follow what the > use cases are as it is very > verbose. > > On Tue, Apr 18, 2017 at 11:27 > AM, Phil Hunt > > ; > wrote: > > > All, > > > > > > Dick asked me if I would enumerate the SCIM use cases. Here is the SCIM > > > case. Happy to put these somewhere in a working group document. > > On Wed, May 3, 2017 at 4:16 > PM, Phil > Hunt >wrote: > > My understanding was you > wanted informal cases not > IDs. The SCIM cases have > been posted to the mailing > list. I believe Marius is > close on the RISC cases. > > Phil > > Oracle Corporation, > Identity Cloud Services > Architect & Standards > > @independentid > > www.independentid.com > > > phil.hunt@oracle.com > > > On May 3, 2017, at > 3:56 PM, Dick Hardt > > > wrote: > > Phil / Marius > > At the Chicago > meeting, the two of > you agreed to work on > a document containing > use cases you > considered to be > relevant for secevent > so that the WG could > decide which ones were > in scope and which > ones were out of scope. > > Checking in on the > status of the use case > document. Would you > provide an update when > you have a chance? > > /Dick > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=HWdy4Q9fHAYB3f-DZ2GWUJnaZDGcZQRaMexC2oHuR7g&s=JTwCxbXPzY_A62IiywTMIjRB-XsMY8UPafBs4oPwOTc&e= > > > > -- > > Subscribe to theHARDTWARE > mail > list to learn about projects I > am working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bAI2H661a1QkItfplrd3RIM36dgAhF4WdbWxW8BOy4Q&s=fzkXYKa7l9vPc2VrpDeaBZo7bH9cDrk9wUethVbuCS8&e= > > > > -- > > Subscribe to theHARDTWARE > mail > list to learn about projects I am > working on! > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=gwGItrqQynlr86zXGtWnR-LWrcrcTS6Ly1w14yDo0vk&s=t5e3IvZ_e-KRHUBVMfjtwKEs74yLZva4z-6OkkgmSjo&e= > > > > > -- > > Subscribe to the HARDTWARE mail list to > learn about projects I am working on! >